Недавно в Биллинге Yandex.Cloud появились бюджеты. Бюджет — это способ контролировать расходы на потребление ресурсов в Yandex.Cloud. В бюджете вы устанавливаете сумму расходов для определенных ресурсов за определенное время и настраиваете, при достижении какого порога потребления и кому будут отправлены уведомления.
Ещё одна новость: в Биллинге появилась интеграция с DataLens. Это простой и удобный способ понять, на что расходуются средства в облаке.
Наши пользователи могли бы заметить: ну как же — у вас всегда был раздел Детализация. Да, это так, но интеграция с DataLens выводит анализ статистики потребления и затрат на новый уровень.
К существующим разрезам (облако, сервис и продукт) добавляются каталоги, ресурсы и метки. Это позволит находить ответы на такие вопросы, как:
на какую виртуальную машину уходит больше всего средств,
как распределяются затраты и потребление по проектам.
Актуальность данных близка к реальному времени. Вы можете выгрузить данные в CSV/XLSX и автоматически их обработать. Так, например, вы можете генерировать и рассылать счета клиентам.
Для того, чтобы воспользоваться новыми возможностями, создайте новое подключение DataLens с типом Yandex Cloud Billing.
Используйте предустановленный Yandex Cloud Billing Dashboard или настройте дашборд под свои запросы.
Недавно Yandex.Cloud и Ernst & Young провели первое исследование применения облачных сервисов российскими компаниями. А также их мотивов и барьеров к внедрению. yandex-cloud.vedomosti.ru
Сначала исследователи провели глубинные интервью с 15 руководителями крупных компаний из разных отраслей рынка. Полученные данные и гипотезы проверили и скорректировали с помощью опроса представителей более 700 российских компаний.
Компании изначально идут в облака под давлением рынка, а приходят к обновлению бизнес-процессов.
«Так, мы выявили, что возросшая потребность создавать цифровые продукты приводит компании к облаку как к более комплексному технологическому решению», — Антон Устименко, партнер EY.
С увеличением объема данных и нагрузки на сервисы, компании все чаще приходят к облачным платформам, потому что не могут отвечать на вызовы рынка на одной только своей инфраструктуре. И с самого начала использования облака компании сталкиваются с эффектом перемен на уровне операционных бизнес-процессов. Участники исследования отмечали, что применение облака способствует трансформации самой операционной модели бизнеса, повышению скорости создания новых продуктов и снижению расходов на ИТ.
Кто инициирует переход в облако и отвечает за бюджет
Среди участников опроса 50% отметили повышение прозрачности и ответственности за затраты ИТ-отдела с переходом в облако, 46% согласились с тем, что повысилась ответственность за данные, а 35% рассказали, что облаком пользуются не только ИТ-специалисты, но и сотрудники бизнес-подразделений.
Это подтверждают данные о том, кто инициирует применение облаков: в 48% опрошенных компаний инициатива была именно за бизнесом. В 24% компаний из исследования ответственность за «облачный» бюджет также уже перенесена на бизнес-подразделения.
Чего боятся компании
Главный страх компаний перед облаками — потерять данные и попасть в зависимость от провайдеров облачной платформы. Так ответила половина респондентов исследования, которые уже перешли на облачные решения и 46% тех, кто только планирует это. Отсюда берется популярное компромиссное решение — переходить в облако из собственной инфраструктуры. То есть работать по гибридной модели, при которой в облако переводится только часть функций. Это мнение разделяет 67% участников исследования.
«Переход от потребления к созданию — это и есть то качественное изменение в бизнесе, которое ускоряется благодаря применению облачных платформ», — Олег Коверзнев, операционный директор Yandex.Cloud.
Как выбирают провайдера
При выборе облачного провайдера компании назвали важнейшим фактором интеграцию с собственной инфраструктурой. Это нужно, чтобы после тестирования продукта в облаке дальнейшее развитие перевести на развернутые к тому времени собственные мощности. Таким образом, переезд в облако и обратно становится частью жизненного цикла продукта.
Диагностика с помощью системных таблиц
Для проведения внутренней интроспекции состояния базы данных пользователи платформы с помощью нового веб-интерфейса могут осуществлять запросы в специальные системные таблицы (system views). Обращения выполняются с помощью YQL-запросов.
Анализ данных из системных таблиц позволяет выполнять диагностику по таблицам, запросам и данным БД:
получить информацию о размерах и нагрузке на партиции таблиц;
посмотреть топ долгих запросов, запросов с наибольшим потреблением CPU или читающих наибольшее количество данных;
посмотреть подробную информацию о выполняющихся запросах с одинаковым текстом.
Ссылки на наиболее востребованные запросы к системным таблицам можно найти в новом разделе Диагностика. Перейдя по ссылке, в редактор YQL будет загружен необходимый запрос, пользователю останется только его выполнить.
Резервные копии
С помощью нового интерфейса стало удобнее управлять резервными копиями. Вы можете создать задание для резервного копирования и запланировать график его выполнения, восстановить данные из резервной копии в нужную базу данных или в отдельную директорию внутри.
Yandex Query Language (YQL)
Теперь при выполнении YQL-запроса можно посмотреть на результаты его исполнения, статистику выполнения, а также его EXPLAIN PLAN.
Навигация по базе данных
Мы переработали инструменты навигации по базе данных и добавили контекстные меню для всех объектов, с помощью которых вы можете:
скопировать полный путь к таблице, а затем вставить его в редактор YQL-запросов;
вызвать просмотр информации об объекте;
сформировать DML-запрос для записи;
сформировать DML-запрос для выборки данных;
удалить объект.
Сниппеты подключения к базе в любом месте навигации
Мы упростили доступ к сниппетам с кодом для подключения к базе, теперь они доступны в любом месте навигации по базе. Находясь на любой странице интерфейса, пользователь может быстро подсмотреть сниппет для подключения к базе данных на любом доступном языке программирования.
Работа с таблицами
С помощью нового интерфейса встроенного редактора таблиц вы можете создавать и редактировать таблицы. Также он поможет задать схему таблицы и сформировать вторичные индексы при создании таблицы.
При создании таблицы вы можете выбрать политику начального партицирования, определить количество партиций при выборе равномерного партицирования или в явном виде указать партиции и границы ключей.
В том же разделе можно управлять свойствами автоматического масштабирования, например, автопартицированием по размеру и нагрузке. А с помощью расширенных настроек указать размер партиции для автоматического партицирования по размеру, задать ограничения по количеству партиций и, при необходимости, включить фильтр Блума.
Для существующих таблиц доступно создание, изменение или удаление созданных вторичных индексов. Причем, на все время построения индекса таблица остается доступной для чтения и записи.
Новый интерфейс позволяет посмотреть полную информацию, схему и свойства таблиц, включая расширенные настройки и опции партицирования. Вы можете получить сведения о вторичных индексах и о партициях таблицы, с границами партиций, сведениями о количестве строк и размере партиции.
Мы улучшили предварительный просмотр таблиц: теперь доступно отображение столбцов с типом JSON и постраничное листание. И прямо из интерфейса вы можете добавить строку в таблицу, что очень удобно для экспериментов с данными.
Бесплатный тариф DataLens теперь доступен без привязки карты
Мы существенно упростили подключение Yandex DataLens для новых пользователей. Даже если у вас пока еще нет облака и платёжного аккаунта Yandex.Cloud, для быстрой визуализации данных вам достаточно:
Перейти на datalens.yandex.ru.
Указать аккаунт на Яндексе.
Активировать бесплатный тариф DataLens следуя инструкциям на стартовой странице.
Пользуясь бесплатным тарифом, вы можете полноценно работать с DataLens, настраивая подключения к собственным источникам данных.
Создание платежного аккаунта и привязка карты (или реквизитов вашего юридического лица) потребуются, если вам нужны:
платные продукты в маркетплейсе DataLens;
платный тариф «Стандарт» для DataLens и расширение лимита внешних сессий согласно тарифам;
другие сервисы Yandex.Cloud, включая управляемые базы данных для надежного хранения и обработки данных в облаке.
Google Sheets в качестве источника
Мы реализовали один из самых популярных запросов для DataLens в нашем сообществе. Теперь при создании нового подключения DataLens вы можете выбрать Google Sheets.
Подключение к Google Sheets является развитием сценариев использования простых CSV. Теперь обновление данных будет происходить бесшовно, без необходимости загрузки новой версии файла и подмены подключения.
Особенности коннектора
Поддерживается полный набор функций DataLens.
На данный момент поддерживаются только документы с доступом по ссылке (доступ «Anyone with the link»).
Используется тот лист таблицы, который был указан в ссылке. Для указания конкретного листа необходимо скопировать ссылку из адресной строки, а не из управления доступом (содержит #gid=… в ссылке).
При загрузке используется кеш, время жизни — до 5 минут.
На данный момент используется представление данных листа через Google Charts — этим обусловлено определение имён колонок, обработка типов значений и представление других возможностей Google Sheets.
Коннектор к детализации биллинга вашего облака
Еще один новый тип подключения — детализация биллинга. Он позволяет анализировать детальные данные о потреблении облачных ресурсов (инфраструктурные сервисы, управляемые базы данных и другие платные сервисы).
К существующим разрезам, доступным в консоли Yandex.Cloud (это облако, сервис и продукт), добавлены данные по каталогам, ресурсам и меткам. А это, в свою очередь, позволяет делать расширенную ad-hoc аналитику по потреблению и находить ответы на такие вопросы, как:
на какую виртуальную машину уходит больше всего средств,
как распределяются затраты и потребление по проектам.
Актуальность данных близка к реальному времени. Вы можете выгрузить данные в CSV/XLSX и автоматически их обработать. Так, например, вы можете генерировать и рассылать счета клиентам.
Коннектор позволяет развернуть стандартный дашборд и доработать его под свои нужны. Для того, чтобы воспользоваться новыми возможностями, создайте новое подключение DataLens с типом Yandex Cloud Billing.
Иерархии и drill-down
Долгожданные иерархии с drill-down теперь в DataLens!
Создать и настроить иерархию можно в несколько кликов на уровне чарта, нажав на кнопку +.
Интерактивный пример встроенного чарта:
В качестве источника использовали документ Google Sheet.
Клик по строке в таблице — переход на уровень ниже с фильтрацией.
Путь над таблицей отображает сделанные переходы по узлам дерева.
Клик по значению, указанному в пути — возврат к выбранному уровню иерархии.
Клики по стрелкам — переход вниз/вверх по иерархии.
Цвет и размер шрифта в индикаторах
Для чартов типа индикатор теперь можно указать цвет шрифта из существующей палитры, а также выбрать один из 4 предустановленных размеров. Несколько счетчиков при подключении к Яндекс.Метрике и AppMetrica
Теперь в режиме прямого доступа можно подключаться к нескольким счетчикам Яндекс Метрики и AppMetrica.
В датасетах Метрики появились измерения Счетчик и Счетчик (id) по которым можно группировать данные. Если вы давно создавали датасет и у вас нет таких полей, нажмите в датасете кнопку Обновить поля и сохраните его.
Kubernetes можно установить на своем оборудовании, либо использовать managed-решение от облачного провайдера. При самостоятельной установке on-premise вы можете более гибко контролировать процесс настройки, но есть риск столкнуться с определенными сложностями.
Если вы уже пробовали разворачивать и поддерживать кластер на своем оборудовании, то, возможно, знакомы с ними. Если только планируете это сделать — прочитайте статью, чтобы разобраться в преимуществах управляемого Kubernetes.
В статье мы расскажем про шесть причин перейти на Yandex Managed Service for Kubernetes®, чтобы избежать сложностей развертывания и администрирования кластера Kubernetes on-premise. Заметим, что это не все преимущества, которые дает управляемый Kubernetes, а только самые значимые, на наш взгляд.
Легко установить и настроить кластер
Kubernetes — сложная система, для установки и настройки которой нужны определенные знания и навыки. Чтобы получить стабильную и безопасную систему, важно правильно установить и настроить кластер: права доступа, сетевые настройки, мониторинг, резервное копирование, файловое хранилище и многое другое.
Чтобы это сделать, необходим специалист с определенными навыками. А лучше два, чтобы они подменяли друг друга на время отпусков и болезней. Хорошо, если у вас в компании уже есть такие люди. Если нет, потребуется время, чтобы их найти или обучить. При этом нужно постоянно поддерживать их квалификацию, потому что Kubernetes развивается и в нем появляются новые возможности и особенности.
Чтобы избавиться от сложностей установки и настройки кластера, можно воспользоваться управляемым Kubernetes. Создать готовый кластер в облаке сможет любой технический специалист, знакомый с Kubernetes на базовом уровне. Для этого не нужны глубокие знания администрирования, достаточно понимать основные концепции, чтобы выбрать параметры сети, группы безопасности, количество подов на узле.
Кластер создается в веб-интерфейсе несколькими кликами. Облачный провайдер выполнит за вас все основные настройки и интеграции, настроит резервное копирование, подключит мониторинг и настроит сеть.
Кроме UI-интерфейса Yandex.Cloud также предлагает возможность создания и управления кластером через API, CLI, SDK и Terraform. Главное преимущество такого способа — автоматизация рутинных задач по созданию и управлению ресурсами кластера. Облачный провайдер берет на себя большую часть задач по установке и настройке кластера, что ускоряет процесс развертывания и исключает необходимость иметь профильных специалистов в штате компании.
Кластер обновляет облачный провайдер
Как и любую систему, кластер нужно обновлять. В решении on-premise обновлять и тестировать кластер вам придется самостоятельно. А так как Kubernetes довольно сложен в освоении, не исключена вероятность ошибок, исправлять которые придется самостоятельно, что потребует много времени. А обновить кластер без простоя — еще более сложная задача.
В Managed Service for Kubernetes облачный провайдер сам обновит ваш кластер. Мы предварительно тестируем новые версии Kubernetes и только после этого устанавливаем их на кластеры клиентов. Вам остается лишь проверить корректность работы сервисов и приложений в новой версии Kubernetes. Как клиент может контролировать процесс обновления:
Вы выбираете расписание установки обновления. Можно указать конкретные дни недели и время. Например, в ночь с пятницы на субботу, чтобы в случае непредвиденных ситуаций еще оставалось время до понедельника. При этом перед установкой обновления мы вас обязательно оповестим.
Вы можете отключить автообновление и устанавливать каждое обновление отдельно, по мере необходимости. Это полезно, когда нет возможности заранее выделить единое время для установки всех обновлений.
У Kubernetes есть три релизных канала для обновления:
Rapid. Содержит самые свежие версии Kubernetes. На канале часто появляются минорные обновления с новой функциональностью и улучшениями. Рекомендуем для непродуктивных сред — разработки и тестирования — потому что тут раньше всего появляется функционал, который скоро появится в продуктивном канале regular.
Regular. Хорошо протестированные версии. Сюда они попадают из канала rapid. Мы рекомендуем использовать канал для большинства продуктовых сред.
Stable. Самые стабильные версии, которые включают в основном исправления ошибок и проблем безопасности. Сюда они попадают из канала regular. Этот канал мы рекомендуем, если вы хотите как можно реже обновлять кластер. Например, в Kubernetes работают второстепенные приложения, которые не нужно постоянно дорабатывать и тестировать. Также этот канал подойдет, если у вас долгий цикл разработки приложений.
Поддерживается автомасштабирование узлов
Kubernetes умеет горизонтально автомасштабироваться, то есть добавлять и освобождать узлы по мере нагрузки. Когда нагрузка на кластер растет — автоматически подключаются новые узлы, чтобы ваши приложения не тормозили. А когда нагрузка падает, ненужные узлы освобождаются.
Такая возможность есть в любой установке Kubernetes, даже on-premise. Но если настраивать автомасштабирование на своем оборудовании, необходим постоянный резерв свободных машин. При этом большую часть времени резервные машины скорее всего будут простаивать. К тому же не исключена вероятность, что в момент особо высокой непредвиденной нагрузки может не хватить даже этих резервов.
Облачный Kubernetes лишен этих недостатков:
Вам не нужно думать о простое оборудования. При создании кластера вы выбираете минимальное и максимальное количество рабочих узлов. Когда нагрузка небольшая, в вашем кластере будет минимум узлов. Когда нагрузка возрастает — кластер сам подключит дополнительные узлы из ресурсов облака.
Облачный провайдер обладает огромными вычислительными ресурсами и может масштабировать ваш кластер вплоть до любого необходимого числа узлов. Ваша система сможет выдержать даже очень высокие нагрузки.
Можно создать региональный отказоустойчивый кластер
При создании продуктового кластера важно позаботиться об отказоустойчивости. Как правило, для этого создаются несколько реплик мастер-узлов.
Если разворачивать кластер на своем оборудовании, как правило, все узлы будут находиться в одном дата-центре или географической зоне (городе или районе). Дата-центры обеспечивают надежность инфраструктуры резервированием, дублированием критических узлов и гарантируют SLA. Но в случае аварии природного или техногенного характера, а также человеческого фактора, ЦОД перестанет функционировать и вы полностью потеряете доступ к кластеру.
Managed-решение Yandex.Cloud позволяет создать региональный отказоустойчивый кластер. У нас есть три собственных дата-центра, расположенных во Владимирской, Рязанской и Московской областях. Если в одном из дата-центров произойдет авария, мастер-узлы в остальных дата-центрах продолжат работать и ваши приложения будут доступны.
А тестовые среды не предъявляют таких требований к отказоустойчивости, для них вы можете создать зональный кластер с одним мастер-узлом. Это будет намного дешевле, чем региональный отказоустойчивый кластер.
Работает с RBAC и IAM
Большие компании используют системы учетных записей, такие как Active Directory или G Suite. И для того чтобы интегрировать их с кластером Kubernetes, необходимо устанавливать и настраивать дополнительные инструменты.
В Managed Service for Kubernetes вы можете подключить систему и использовать свои учетные записи без дополнительных настроек. Для этого на уровне IAM настраивается федерация через протокол SAML. И тогда учетные записи ваших пользователей интегрируются с платформой Yandex.Cloud и им можно назначать роли.
Наш IAM является дополнением к стандартному Kubernetes RBAC. Используя обе системы, можно решать более сложные задачи по разграничению доступа. Например,
разработчику из всех ресурсов платформы необходим доступ только к кластеру Kubernetes. Для этого внутри облака ему выдаются минимальные права, достаточные лишь для подключения к кластеру. А внутри Kubernetes при помощи RBAC ему добавляются необходимые полномочия на объекты кластера.
Удобный UI «из коробки»
У Kubernetes нет стандартного графического интерфейса управления. Существуют сторонние разработки от сообщества, которые нужно устанавливать, настраивать и предоставлять к ним доступ.
Мы разработали собственный интерфейс управления, доступный всем пользователям Managed Service for Kubernetes. Он уже интегрирован с Yandex IAM, что позволяет легко раздавать полномочия. Вы можете использовать наш дашборд вместо одного из сторонних или вместе с ним. Вот несколько его ключевых возможностей:
Детализация узлов, деплойментов, подов и сети. По каждому из этих объектов можно увидеть текущее состояние, посмотреть перечень событий и логов. Это позволяет отлаживать приложения без необходимости устанавливать дополнительные инструменты в кластер. Из детализации деплоймента можно увидеть, какие поды создались на его основе, и сразу перейти к ним.
Детализация потребления ресурсов. По каждому узлу или поду можно увидеть, сколько тратится CPU, памяти и сетевых ресурсов.
Настройка детализации. В каждой детализации можно добавлять или убирать поля для отображения.
Гибкий фильтр событий. В кластере генерируется довольно много событий, поэтому мы создали гибкий фильтр. Можно фильтровать по пространству имен, уровню или сущности.
Мы постоянно дорабатываем дашборд, поэтому в будущем у него появятся новые возможности. Нашим клиентам ничего не нужно устанавливать или обновлять, они сразу будут получать новые возможности.
Краткие итоги
Мы рассмотрели шесть главных преимуществ Managed Service for Kubernetes® перед классическими on‑premise‑кластерами Kubernetes.
Но это не все, что может предложить Yandex.Cloud для решения задач Kubernetes. С помощью платформы вы можете решать и другие задачи, например находить уязвимости в образах контейнеров, шифровать секреты в etcd‑хранилище или интегрироваться с инструментами CI/CD. Более подробно об этих и других возможностях вы можете узнать из нашего вебинара «Kubernetes. Managed на все 100%».
Любой, кто обращает внимание на рынок жестких дисков так же внимательно, как Backblaze, уже знает все о быстром росте популярности Chia — «зеленой» альтернативы Биткойну — и о том, какое влияние она оказывает на мировые поставки жестких дисков. Если вы еще не слышали о Чиа, ознакомьтесь с краткой записью ниже, чтобы получить дополнительную информацию. Но этот пост предназначен для многих фермеров чиа, которые уже погрузились в сельское хозяйство и теперь сталкиваются с пустыми полками в поисках решений для хранения на своих участках.
Помня об этой нехватке, наша команда приступила к изучению экспериментального решения, которое позволит обрабатывать участки Chia, хранящиеся в облачном хранилище B2. Мы рады сообщить, что теперь фермеры чиа могут хранить и обрабатывать свои участки в Backblaze B2.
Итак, если вы хотите принять участие в сенсации Chia, не тратя много средств на труднодоступные жесткие диски большой емкости, теперь есть инновационный способ начать работу с доступным масштабируемым облачным решением.
Chia против биткойнов: Chia — это новая криптовалюта, в которой используется алгоритм доказательства свободного места. В отличие от алгоритма доказательства работы, поддерживающего Биткойн, который требует больших затрат ресурсов и ресурсов процессора, и энергии, Chia был разработан для минимизации энергопотребления. В результате мы получаем блокчейн с интенсивным хранением. Если вы хотите узнать больше, рекомендуем обратиться к первоисточнику.
Ключи к победе в испытаниях чиа
Участки Чиа не просто бездействуют. Сеть Chia регулярно выдает запросы на соответствие и проверки качества. Проверки качества важны для достижения успеха, но проблемы — когда каждые 512 участков проверяется каждые 10 минут — являются причиной того, что вы занимаетесь сельским хозяйством.
Если один из ваших сюжетов выбран для матча, вам необходимо получить «полное доказательство», чтобы получить вознаграждение, что требует около 64 поисков жесткого диска и доставки полного доказательства остальной части одноранговой сети. менее чем за 30 секунд, прежде чем «повелители времени» Чиа двинут блокчейн дальше.
Это создает две проблемы, которые могут мешать вам спать по ночам, если вы пытаетесь фармить чиа:
Проблема 1: Где хранить участки в масштабе.
Учитывая, что текущее расчетное сетевое пространство, занятое участками Chia, составляет 20 эксабайт (и растет экспоненциально!), Случай показывает, что только один из ваших участков будет выигрывать примерно раз в 96 лет. Это все равно, что ждать всю жизнь кукурузного початка, а не весело. Итак, вы хотите иметь много участков, чтобы улучшить свои шансы, но вам нужно где-то их хранить, что вы можете себе позволить и которое может расти вместе с вашим сельским хозяйством.
Проблема 2: Управление сложностью масштабирования хранилища.
Если вы решите проблему хранения, вам также понадобится способ быстро и надежно сделать все графики доступными для чтения и быстрого представления в сети, когда вы выиграете испытание. Вам нужно будет уметь управлять этой сложностью каждую секунду каждый день, пока вы хотите быть фермером. Если вы ждете 96 лет, чтобы получить хоть один кукурузный початок, пропустить день сбора урожая было бы обидно.
Это ключи к победе в матче: достижение масштаба и умелое управление им.
Статус-кво: отдельные фермеры чиа используют жесткие диски для хранения
Для жесткого диска 7200 об / мин с задержкой чтения примерно 10 мс получение проверки качества или полной проверки занимает около 70 мс на подходящую диаграмму. Поскольку ядро Chia кэширует первые семь операций чтения, жесткий диск должен выполнить только 64 поиска при выдаче запроса.
Если диск емкостью 18 ТБ, который может содержать 166 графиков по 108 ГБ на график (при k = 32), достаточно удачлив, чтобы содержать график, который является тем волшебным «одним из 512», жесткий диск достаточно быстро выполняет необходимые операции чтения, потому что Chia была разработана для использования жестких дисков для земледелия. Но жесткие диски могут выполнять только одну из этих операций за раз, поэтому рабочий стол должен выполнять операции последовательно. Даже если вы используете твердотельный накопитель, вам все равно придется выполнять операции последовательно. Опять же, это не проблема для отдельных дисков, поскольку жесткие диски и твердотельные накопители могут выполнять операции очень быстро в отведенное время.
Но даже для тех, кому посчастливилось найти запас готовых дисков емкостью 18 ТБ, которые не были дважды размечены, обеспечение хранилища для количества участков, необходимых фермеру Чиа для обеспечения разумных шансов на успех, будет трудом и капиталом. интенсивный.
Как использовать облачное хранилище для масштабирования участков
Программное обеспечение Chia не было разработано для ведения сельского хозяйства с использованием общедоступного облачного объектного хранилища, и первые тесты, которые мы провели на графиках Chia, хранящихся в облачном хранилище B2, подтвердили это: требуется несколько минут, а не 30 секунд, необходимых для своевременного прохождения проверки качества. В отличие от решения с локальным хранилищем, где данные проверки качества могут кэшироваться ядром, при настройке облачного хранилища производительность снижается до такой степени, что это влияет на вероятность успешного выполнения пользователями задач.
Backblaze B2 Cloud Storage предоставляет объектное хранилище, в котором данные хранятся в виде дискретных объектов, что исключает необходимость использования какой-либо вложенной или иерархической файловой структуры. Это делает B2 Cloud Storage идеальным для масштабирования и использования в качестве исходного хранилища, но как отдельный продукт хранилище объектов не подходит для хранения графиков Chia. Без оптимизации кэширования для повышения производительности и способа одновременного чтения графиков B2 Cloud Storage не смог бы эффективно служить в случае фермерского хозяйства Chia. Но B2 Cloud Storage спроектировано так, чтобы использовать преимущества параллельных операций или потоков, предлагая некоторые преимущества по сравнению со стандартным физическим диском, если они правильно настроены для этого варианта использования (кашля * я писал здесь про потоки! Кашля *).
Наша команда подумала, что было бы интересно создать инструмент, обеспечивающий обходной путь для варианта использования Chia, по четырем веским причинам:
Во-первых: потому что Backblaze Storage Cloud предоставляет оба ключа для успешного выращивания чиа: нет необходимости в выделении ресурсов, и фермеры из чиа могут загружать новые участки с высокой скоростью и масштабом. Backblaze Storage Cloud обслуживает почти 500 миллиардов файлов с исключительной надежностью и доступностью.
Во-вторых: стоимость хранения участков Chia в Backblaze B2 является привлекательной с финансовой точки зрения и составляет 5 долларов США за ТБ в месяц. Согласно Chia Calculator, использование облачного хранилища B2 для хранения участков было бы прибыльным, в зависимости от темпов роста сетевого пространства и текущей цены монеты Chia.
В-третьих: команда инженеров и инженеров Tiger, включая меня, думала, что это будет интересным и полезным (и увлекательным) экспериментом.
Наконец: та же команда считала, что мы могли бы включить Chia-сельское хозяйство участков, хранящихся в B2 Cloud Storage, взломав код того, как распараллеливать операции в Chia.
Помня об этом, наша команда Tiger приступила к работе. Инструмент для монтирования Backblaze B2 в качестве файловой системы был необходим, поскольку Chia изначально не поддерживает API Backblaze B2 Native или S3 Compatible. После некоторого тестирования наша команда остановилась на B2_fuse, поскольку наши инженеры, которые будут над этим работать, уже были знакомы с исходным кодом.
Выбрав B2_fuse, наши инженеры добавили алгоритм предварительной выборки для кэширования операций чтения, чтобы решить проблему ядра, упомянутую выше. Это улучшило бы производительность, но поскольку считывание с жесткого диска по-прежнему выполнялось по одному, оставалось место для дополнительных улучшений. Очевидно, что параллельное выполнение операций значительно повысило бы вероятность успеха, и после некоторых копаний один из наших инженеров нашел PR (запрос на вытягивание), который добавлял параллельное чтение и еще не был объединен в проект Chia.
Благодаря оптимизации кэширования в B2_fuse и добавленной функциональности параллельного чтения время проверки для графика Chia, хранящегося в облачном хранилище B2, сократилось до секунд. Это обеспечивает загрузку участков Chia в Backblaze B2 и их представление в сети Chia для ведения сельского хозяйства без необходимости использования дорогостоящего сервера в центре обработки данных.
Наши успешные тесты были проведены с использованием вычислительного экземпляра, работающего в регионе Запада США, с учетной записью Backblaze B2, который также находится в регионе Запада США. Попробуйте, и вы увидите целое поле метафорических культур — все готово к тому, когда придет вызов «один из 512».
Если вы хотите попробовать это решение, настройте учетную запись Backblaze B2 сейчас и получите обновленную версию B2_fuse (или внесите свой вклад в проект) вместе с инструкциями о том, как получить PR с параллельными чтениями здесь: github.com/Backblaze-B2-Samples/b2fs4chia
Поскольку эта поддержка носит экспериментальный характер и команда Backblaze знает, что многие фермеры Chia будут рады ее опробовать, мы просим фермеров ограничить хранение делянок Chia до 100 ТБ или связаться с нашим отделом продаж, чтобы обсудить что-то более крупное.
В Спринтхост в тестовом режиме появилась услуга защиты хостинга от DDoS-атак от компании DDoS-Guard.
DDoS-Guard использует технологию обратного прокси, которая позволяет перенаправить DDoS-атаку на защищенный IP-адрес. Далее весь входящий трафик сканируется и очищается от всех паразитных пакетов. Общая канальная емкость сети более 1,5 Тб/сек, что обеспечивает бесперебойную работу 24/7.
Свяжитесь с нами обратным письмом, если:
Готовы абсолютно бесплатно протестировать услугу на своем аккаунте и посмотреть на защиту в действии;
Хотите на постоянной основе использовать защиту от DDoS-Guard для своего проекта.
Приглашаем вас на вебинар «Рекомендательные системы: архитектура и применение». Старт 22 июня в 12:00 (МСК).
Рекомендательная система — сплошная польза для бизнеса. Это и экономия ресурсов, и увеличение среднего чека, и допродажи, и лояльность пользователей.
Главное — всё правильно подготовить и интегрировать.
На вебинаре разберём, как собрать эффективный движок для рекомендательной системы. Покажем архитектуру современного движка на базе платформы данных Yandex.Cloud, посмотрим кейсы и рабочие алгоритмы.
Опытом построения рекомендательных систем поделятся наши коллеги из компании GlowByte — эксперты в области BI, Big Data и автоматизации маркетинга. cloud.yandex.ru/events/368
Начинаем лето с отличных новостей! Впервые на FirstDEDIC доступны конфигурации выделенных серверов на базе AMD EPYC — флагмана второго поколения, мощного 64-ядерного процессора EPYC 7742.
Технические характеристики процессора:
64 ядра,
128 потоков,
256 Мб кэш-памяти третьего уровня,
до 3,4 ГГц в турборежиме,
2,25 ГГц в базовом режиме,
уровень TDP — 225 Вт,
8 каналов памяти DDR4-3200,
поддержка ECC-памяти.
Второе поколение EPYC носит кодовое названием «Rome», построено на архитектуре Zen 2 и предлагает больше производительности по сравнению не только с предыдущим, но и с близкими по техническим параметрам конкурирующими аналогами.
Производителю удалось добиться прироста мощности за счёт изменения компоновки ядер внутри процессора, обеспечив их максимальное количество. Инновация строится на использовании так называемых чиплетов — отдельных кристаллов, связанных быстрой шиной Infinity Fabric. При этом плотность размещения транзисторов увеличилась вдвое, и во столько же уменьшилось энергопотребление. Сама по себе шина Infinity Fabric тоже была ускорена, ее ширина выросла с 256 до 512 бит, что сократило задержки при обмене данными между ядрами.
Также в процессорах AMD EPYC второго поколения оптимизирована работа кэш-памяти первого уровня и увеличен объём кэша третьего — до 256 Мб.
Дополнительным преимуществом стало улучшенное управлением питанием, которое позволяет наиболее эффективно работать разному количеству ядер на максимальной частоте. Так восемь активных ядер могут работать на 3,4 ГГц, а все 64 — на 3,2 ГГц.
Кроме того, второе поколение процессоров AMD EPYC не только унаследовало от предшественника защиту от таких угроз, как Spectre, Meltdown и прочих, но и получило в том числе аппаратные патчи усиленной защиты от всех версий Spectre, которые не требуют постоянного обновления прошивки.
Результаты тестирования
Чтобы вы могли убедиться в мощности предлагаемого решения, мы протестировали топовый многоядерный процессор AMD EPYC 7742, используя бенчмарки Sysbench и Geekbench 5, и сравнили полученные результаты с показателями самых производительных в нашей линейке процессоров Intel Xeon Scalable — Gold 6230R и Gold 6240R.
В тестировании использовались двухпроцессорные конфигурации:
2хGold 6230R — 52 ядра, 2,1-4,0 ГГц,
2хGold 6240R — 48 ядер, 2,4-4,0 ГГц,
2хEPYC 7742 — 128 ядер, 2,25-3,4 ГГц.
По результатам теста Sysbench топовый AMD EPYC в 2,5 раза опережает соперников. Разница составляет 159,2% с 2хGold 6230R и 155,6% с 2хGold 6240R.
Что касается результатов теста Geekbench 5, то в однопоточном режиме AMD EPYC идет почти наравне с Intel Scalable — разница составляет около 5%. Тут все решает тактовая частота, а у Intel в турборежиме она выше. Зато в многопоточном режиме, где последнее слово остается за ядрами, лидерство AMD EPYC заметно сразу: разница с с 2хGold 6230R составляет 51,9%, а с 2хGold 6240R — 54,1%.
Особенности серверной платформы:
двухпроцессорные конфигурации,
накопители NVMe,
оперативная память от 128 Гб до 2048 Гб.
Платформа для сборки конфигураций на базе AMD 2xEPYC 7742 поддерживает объём оперативной памяти до 2 Тб, а кроме того позволяет подключать до 10 накопителей NVMe. Максимальный объём одного диска — 8000 Гб.
Конфигурации на базе AMD 2xEPYC обеспечат вам высокую производительность, безопасность и масштабируемость для самых ресурсоемких рабочих нагрузок. Сборка сервера в течение 24 часов.
Отличное начало лета 2021 года, не правда ли?
Команда SpaceCore подготовила для Вас масштабные скидки на все виды VDS и Выделенных серверов!
До 20 июня Вы можете приобрести абсолютно любой виртуальный сервер со скидкой 15%!
Помимо этого, на все Выделенные серверы активирована скидка 10%!
Мы предоставляем производительное оборудование в 5-ти разных странах мира, с игровой защитой от DDoS и без.
Все это по низким для пользователя ценам. Успей ухватить выгодное предложение!
