Рейтинг
0.00

Yandex Cloud

5 читателей, 245 топиков

С 1 августа снизятся расценки на виртуальные машины с ОС Windows



С 1 августа 2019 года для всех пользователей сервиса Yandex Compute Cloud в Яндекс.Облаке снижаются расценки на виртуальные машины с операционной системой Windows. Цена меняется для виртуальных машин на платформе Intel Broadwell с гарантированной производительностью 20% vCPU и для виртуальных машин на платформе Intel Cascade Lake с гарантированной производительностью 20% vCPU и 50% vCPU.

Вот как изменится цена за использование ОС Windows Server за 1 vCPU в час:

Подробнее о том, из чего складываются цены на виртуальные машины, читайте в разделе Тарифы.
cloud.yandex.ru/docs/compute/pricing

Новые возможности сервисов управления базами данных



Размещение баз данных в Яндекс.Облаке — популярный сценарий использования нашей платформы. Для всех СУБД мы обеспечиваем автоматическое резервное копирование, отказоустойчивость, обновление минорных версий и инструменты мониторинга. Также мы постоянно работаем над функциональностью облачных сервисов, чтобы вы могли легко размещать базы данных и работать с ними в Облаке.

Новая версия СУБД PostgreSQL 11
В Managed Service for PostgreSQL теперь доступна версия СУБД PostgreSQL 11.

Ключевые изменения в новой версии:
  • расширены возможности секционирования таблиц и параллельного выполнения запросов;
  • добавлены хранимые процедуры на SQL, поддерживающие внутренние транзакции;
  • добавлена JIT-компиляция фрагментов запросов.
Вы можете выбрать PostgreSQL 11 при создании нового кластера в консоли управления, через API и CLI.
cloud.yandex.ru/docs/managed-postgresql/operations/cluster-create
www.postgresql.org/docs/11/release-11.html

Детальную информацию о новой версии PostgreSQL можно найти на официальной странице релиза.

Логическая репликация
Логическая репликация поддерживается с версии PostgreSQL 10. Помогает автоматически перенести базу данных из вашей инфраструктуры в Managed Service for PostgreSQL с минимальным временем простоя.

Логическая репликация позволяет не только перенести БД между одинаковыми версиями СУБД, но и мигрировать базу данных с 10 на 11 версию PostgreSQL. Просто пройдите шаги миграции, настроив репликацию c сервера-источника с PostgreSQL 10 на сервер-приемник с PostgreSQL 11.

Расширенные настройки СУБД и настройки пользователей в консоли управления
Теперь вы можете просматривать и изменять расширенные настройки СУБД для кластеров PostgreSQL в консоли управления, а не только через CLI и API. Задать необходимые настройки можно как в процессе создания нового кластера БД, так и через кнопку Изменить кластер для существующего кластера.

Кроме того, в Managed Service for PostgreSQL доступны расширенные настройки для пользователей. Это позволяет задавать для отдельных пользователей значения параметров, которые превалируют над настройками кластера. Например, для всего кластера вы можете установить lock_timeout в 1 секунду, а для конкретного пользователя, из-под которого выполняете DDL-команды (изменения схемы), поставить lock_timeout побольше или отключить его вообще.

Обновление версий ClickHouse
Теперь вы можете изменить мажорную версию СУБД ClickHouse для существующих кластеров БД.

Список доступных версий можно посмотреть на экране создания или изменения кластера в консоли управления. Вы можете изменить версию как на более свежую, так и на более старую, если это необходимо. Операция доступна через консоль управления, API и CLI.

Шардирование в ClickHouse
В Managed Service for ClickHouse теперь есть возможность не только вертикального масштабирования кластеров БД, но и горизонтального за счёт автоматического создания шардов в кластерах ClickHouse.

Шардирование помогает расширять пул доступных вычислительных ресурсов кластера и объём хранилища. При этом конфигурации разных шардов в одном кластере могут отличаться.

Для распределения данных по шардам можно использовать разные механизмы, например ключи шардирования или веса шардов. При правильном распределении ключей пользователь сможет параллельного выполнять запросы над фрагментами данных на нескольких хостах, а скорость обработки данных существенно вырастет. Распределение по весам шардов позволяет сделать вставку данных прозрачной для пользователя.
Подобнее о шардировании таблиц в Managed Service for ClickHouse читайте в документации сервиса.
cloud.yandex.ru/docs/managed-clickhouse/tutorials/sharding

Обновление до High Availability конфигурации
Кластеры ClickHouse с одним хостом теперь можно обновить до конфигурации с высокой доступностью (High Availability, HA) без пересоздания. Раньше вы могли сразу создать кластер в HA-конфигурации, но поменять конфигурацию кластера с одним хостом на HA было нельзя.

Кластер с одним хостом не отказоустойчив и не обеспечивает репликацию данных. HA-конфигурация подразумевает наличие актуальных реплик данных на нескольких хостах кластера: между репликами можно распределить нагрузку; наличие реплик защитит от потери данных в случае сбоя в работе одного из хостов. Для обеспечения репликации ClickHouse использует Apache ZooKeeper. Теперь вы можете добавить хосты ZooKeeper к существующему кластеру БД с одним хостом.

Чтобы обновить ваш кластер до HA-конфигурации:

Managed Service for MongoDB

Новая версия СУБД MongoDB 4.0
В Managed Service for MongoDB теперь доступна версия СУБД MongoDB 4.0.
Одна из ключевых новых функциональностей версии 4.0 — поддержка транзакций, удовлетворяющих требованиям ACID (атомарность, согласованность, изолированность, устойчивость). Транзакции работают в рамках replica set (т.е. внутри одного шарда). Также в новой версии улучшена работа с шардами. Благодаря этому мы поддержали шардирование для кластеров с версией MongoDB 4.0.

Детальную информацию о новой версии MongoDB можно найти на официальной странице релиза.

Обновление кластеров с версии 3.6 до 4.0
Теперь вы можете обновить версию MongoDB с 3.6 до 4.0 для существующих кластеров БД. Операция доступна через консоль управления, API и CLI.
cloud.yandex.ru/docs/managed-mongodb/operations/cluster-version-update

Шардирование в MongoDB
В Managed Service for MongoDB появилась возможность шардирования для кластеров MongoDB версии 4.0. Если ваш кластер развернут с версией 3.6, вы можете обновить его.
cloud.yandex.ru/docs/managed-mongodb/operations/cluster-version-update

Шардирование — стратегия горизонтального масштабирования данных, при которой части коллекций MongoDB размещаются на разных хостах кластера. Горизонтальное масштабирование подразумевает распределение набора данных и нагрузки по нескольким узлам, серверы могут добавляться и для увеличения дисковой емкости. Емкость одной машины или ее скорость могут быть невысокими, но в горизонтально масштабируемом кластере каждая машина обрабатывает лишь часть общей нагрузки и хранит лишь часть общих данных. Это делает систему потенциально эффективнее, чем единственный сервер с большой ёмкостью и быстрыми дисками.

Подробнее о шардировании коллекций в Managed Service for MongoDB читайте в документации сервиса.
cloud.yandex.ru/docs/managed-mongodb/tutorials/sharding

Изменения в условиях использования сервисов Облака



Спасибо за работу с сервисами платформы Яндекс.Облако!
В этом письме мы собрали все изменения в Оферту, которые вступят в силу с 1 августа 2019 года.

Краткое описание изменений:
  • Уточнён пункт 7.1.4. Оферты и добавлены новые способы оповещения об изменениях в работе Платформы: запись в Блоге на Сайте.
  • Уточнены формулировки в разделе 8 Правил допустимого использования.
  • В SLA уточнены условия предоставления компенсации: для получения компенсации нужно направить запрос на компенсацию в течение 30 календарных дней с момента инцидента.

Первая большая конференция Яндекс.Облака — Yandex Scale. Регистрация открыта



На конференции Yandex Scale вы:
  • первыми узнаете главные анонсы будущих сервисов Яндекс.Облака,
  • получите доступ к реальному опыту применения Облака от наших партнёров и клиентов,
  • получите ответы от команды разработки сервисов Облака,
  • обменяетесь опытом с коллегами и найдёте новые контакты ИТ-профессионалов.
Приглашаем вас принять участие и зарегистрироваться одними из первых!
cloud.yandex.ru/events/scale-2019

Яндекс.Облако создаёт новые возможности для бизнеса



Меня зовут Олег Коверзнев, вместе с командой мы создаём Яндекс.Облако, чтобы вы меньше думали о технологиях и больше — о развитии своего дела.
Мы одинаково ценим всех пользователей платформы Яндекс.Облака. Но есть категория компаний, которую мы воспринимаем как партнёров и предлагаем им специальные условия сотрудничества.
Если вы специализируетесь на создании и продвижении собственных программных продуктов для массового рынка или корпоративных клиентов, то мы предлагаем вам стать частью нашей партнёрской экосистемы для компаний-разработчиков.
Что мы можем предложить участникам программы:
  • Ранний доступ к новым сервисам Яндекс.Облака.
  • Бесплатную техническую поддержку на весь срок партнёрства.
  • Возврат* 50% от затрат на Яндекс.Облако во второй и третий месяцы потребления Облака.
  • Возможность получить расширенный грант для тестирования и миграции в Облако.
  • Доступ к закрытому чату сообщества, вебинарам и встречам с инженерами и архитекторами Яндекс.Облака для обмена опытом и знаниями по использованию сервисов Облака.
  • Специальные предложения от других сервисов экосистемы Яндекса (Директ, Трекер, Метрика и др.) для развития вашего продукта.
Программа будет расширяться, следите за новостями! Дать продуктовым компаниям доступ к технологиям и новым возможностям для монетизации — вот та цель, с которой мы создали эту программу. Такие компании, как SkyEng, помогали нам запускать платформу и уже являются частью растущего сообщества наших партнёров.
Оставьте заявку и уже сегодня получите консультацию специалиста по условиям и привилегиям программы.
cloud.yandex.ru/partners/tech

В общий доступ выходит сервис Yandex Container Registry



Ещё один сервис платформы Яндекс.Облака выходит в общий доступ. С 4 июля все желающие смогут пользоваться Yandex Container Registry — сервисом для хранения и управления Docker-образами. Он позволяет управлять самими Docker-образами, их реестрами и репозиториями.

Сервис можно использовать в разработке контейнеризованных приложений. Вы можете настроить вашу систему автоматизации сборки и выкладки приложений на работу с Yandex Container Registry. Реестры ваших Docker-образов будут размещаться в тех же дата-центрах, где находится облачная инфраструктура. Вы избежите расходов на внешний трафик и получите высокую скорость загрузки и скачивания.

А ещё контейнеризацию широко применяют для запуска небольших слабосвязанных сервисов. Так что Yandex Container Registry будет полезен разработчикам микросервисов.

Yandex Container Registry размещает ваши Docker-образы в отказоустойчивом хранилище. Копии образов хранятся в разных зонах доступности. Сервис поддерживает автоматическую репликацию данных: при редактировании, создании и удалении Docker-образа меняется каждая его копия. Так обеспечивается надёжная защита от потенциальных сбоев и потери данных.

Чтобы начать работать с сервисом, вам не придётся осваивать новые API и инструменты. Используйте стандартный интерфейс командной строки Docker — сервис совместим с Docker Registry HTTP API V2.
cloud.yandex.ru/services/container-registry
cloud.yandex.ru/services/iam
cloud.yandex.ru/docs/container-registry/operations/authentication#cred-helper

Сервис интегрирован с сервисом управления доступом Yandex Identity and Access Management. С его помощью вы можете разграничивать права так же, как и в любом другом сервисе Облака. Кроме того, Yandex Container Registry может хранить учетные данные пользователя во внешнем хранилище Docker Engine. Управлять доступом к хранилищу можно с помощью интерфейса командой строки Облака YC CLI.

Подробнее о работе с Yandex Container Registry читайте здесь:

Скидки до 40% на управляемые БД



С 1 июля по 31 июля 2019 года разверните и используйте управляемую базу данных в Облаке в платной версии и получите скидку до 40% на эту базу данных с 1 августа 2019 года на 12 месяцев. cloud.yandex.ru/promo-mdb/

Как получить скидку?
  • Пополните счёт на любую сумму и разверните кластер БД в Облаке.

Используйте эту БД в течение месяца, включая 31 июля.
  • C 1 августа подключится скидка: сервис по управлению базой данных будет доступен по цене со скидкой.

В акции есть ограничения: она распространяется на базы данных, которые вы будете использовать платно в Облаке впервые.
Вы найдёте руководства по миграции баз данных в Яндекс.Облако в документации. Мы подробно описали, как это сделать:
По всем вопросам пишите в техподдержку в консоли управления.
Если после 12 месяцев работы с базами данных в Облаке со скидкой вы останетесь недовольны качеством работы сервиса, мы предоставим вам консультацию нашего инженера, чтобы помочь провести обратную миграцию из Яндекс.Облака.

Как можно использовать прерываемые виртуальные машины Яндекс.Облака и экономить на решении масштабных задач



Сегодня мы хотим рассказать о такой полезной функции Яндекс.Облака как прерываемые виртуальные машины. Это специальная опция, которую вы можете выбрать при создании виртуальной машины, чтобы использовать вычислительные ресурсы по сниженной цене. Что же такого особенного в прерываемых виртуальных машинах, почему они стоят дешевле обычных и в каких случаях разумно их применять?



Мощности Яндекс.Облака, а точнее, инфраструктурного сервиса Yandex Compute Cloud, заметно больше тех, что задействуются пользователями. По умолчанию предполагается, что у пользователей должна быть возможность условно неограниченного масштабирования. Как минимум из этих соображений, без учета других аспектов, доступные ресурсы облачной платформы существенно превышают текущий спрос. Именно на этих свободных мощностях и создаются прерываемые виртуальные машины.

Основные ограничения
Коротко сущность прерываемых виртуальных машин можно описать так: сервис предлагает использовать свои свободные вычислительные ресурсы по меньшей цене при условии, что эти ресурсы могут быть отозваны в любой момент.

В целом прерываемые виртуальные машины работают как обычные виртуальные машины, но для них установлен ряд ограничений:
  • На них не распространяется соглашение об уровне обслуживания (SLA).
  • Не гарантируется возможность создания и запуска.
  • Они могут быть принудительно остановлены в любой момент. Вероятность остановки невелика, однако не равна нулю, может меняться со временем и различаться в разных зонах доступности Яндекс.Облака.
  • Прерываемую виртуальную машину нельзя сделать обычной, а обычную прерываемой. Соответствующий флаг устанавливается один раз и не меняется.
  • Машина обязательно будет остановлена в срок, не превышающий 24 часа.
На практике в подавляющем большинстве случаев прерываемые виртуальные машины отрабатывают все 24 часа, предусмотренные условиями сервиса. Принудительная остановка, как правило, происходит только тогда, когда в конкретной зоне доступности за короткий период создается большое количество обычных виртуальных машин: появляется новый пользователь с серьезными потребностями или массово масштабируются текущие пользователи.

При этом остановленную виртуальную машину можно запустить снова: все данные на дисках сохраняются и при автоматическом и при ручном выключении.

Сценарии использования
Ограничения для прерываемых виртуальных машин вызывают логичный вопрос: как их применять, если ресурсы могут быть отозваны в любой момент? В качестве пояснения приведём несколько возможных сценариев использования.

Пакетная обработка данных
Пакетная обработка подразумевает параллельное исполнение большого количества ресурсоёмких заданий. Это может быть преобразование форматов файлов, обработка и распознавание изображений, ETL-операции. Суть в том, что при пакетной обработке существует очередь заданий и целый набор рабочих процессов (исполнителей), получающих задания из очереди. Если отдельный исполнитель, запущенный на прерываемой машине, остановится, задание будет просто передано следующему исполнителю. Другими словами, остановка одной или даже нескольких виртуальных машин не окажет существенного негативного влияния на процесс и результат обработки.


При пакетной обработке данных речь идет об использовании десятков виртуальных машин. Применение прерываемых машин даёт очень заметную экономию. Сейчас один из главных потребителей производительных прерываемых виртуальных машин с 32 ядрами — давний клиент Яндекс.Облака, компания «Сейсмотек». «Сейсмотек» занимается обработкой сейсмических данных, которые необходимы для разведки газовых и нефтяных месторождений. Сейсморазведка предполагает работу с большими объемами информации. Данные обрабатываются пакетным методом. Компания одновременно использует до 60 с лишним прерываемых машин: суммарно до 2000 vCPU и 4000 ГБ RAM.

Проекты на Hadoop
Hadoop используется для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч недорогих узлов. Предусмотренные в Hadoop механизмы репликации файлов и автоматического перезапуска задач, выполнявшихся на вышедших из строя узлах, обеспечивают устойчивость распределённой системы к отказам отдельных машин. Именно поэтому там, где применяется Hadoop, как минимум часть узлов спокойно может быть развёрнута на прерываемых виртуальных машинах. В случае их досрочной остановки задачи будут отправлены на другие узлы.

Отказоустойчивость веб-сервисов
Постоянную доступность веб-сервиса можно обеспечить с помощью кластера. Кластер состоит из двух и более серверов. Одна из его задач в приложении к веб-сервисам — обеспечить стабильную работу в момент пиковых нагрузок. Характерные примеры: сайты интернет-магазинов или спортивные сайты, где рост трафика привязан к определенным датам. Для магазинов это могут быть традиционные праздники или периоды скидок, а для сайтов спортивной тематики — дни событий, когда идут трансляции, публикуются обзоры и фотоотчёты. В такие моменты объем трафика может увеличиваться в разы.

Кластер должен справляться с наплывом посетителей, распределяя трафик по разным узлам. На период резкого, но непродолжительно роста нагрузки отказоустойчивость можно обеспечивать, добавляя серверы на прерываемых виртуальных машинах. Такой вариант обходится недорого и хорошо справляется со своей задачей. Важно соблюдать одно условие: подобный кластер обязательно должен быть гибридным, то есть включать в себя обычные виртуальные машины. В этом случае даже маловероятная остановка прерываемых машин не приведёт к отказу сервиса.

Проекты на Kubernetes
Kubernetes позволяет автоматизировать развёртывание, масштабирование и управление контейнеризированными приложениями на большом количестве узлов. Одна из основных сущностей, которую можно назвать строительным блоком Kubernetes, — под (pod). Под обеспечивает запуск одного или нескольких контейнеров на одном узле. Узел для каждого пода подбирается и назначается планировщиком Kubernetes. Если отдельный узел с запущенным подом выйдет из строя, планировщик автоматически перенесёт под на узел, работающий в штатном режиме. Такая схема поддержания работоспособности предполагает, что часть узлов можно размещать на прерываемых виртуальных машинах.

Тестирование в практике непрерывной интеграции
Практика непрерывной интеграции строится на частой сборке и тестировании проекта. При этом применяется в основном автоматизированное тестирование. Схематически это выглядит так: создаётся тестовое окружение на виртуальной машине, в него выгружается последний билд приложения, проводится автоматизированное тестирование, результаты тестирования выгружаются, виртуальная машина удаляется. Как правило, тестирование занимает несколько десятков минут, реже — несколько часов.

Традиционно слабыми местами непрерывной интеграции считаются значительные затраты на поддержку самого процесса интеграции и высокая потребность в вычислительных ресурсах. С этой точки зрения и с учетом временных рамок автоматизированных тестов прерываемые виртуальные машины выглядят более чем подходящим вариантом для непрерывной интеграции. Они намного дешевле, а вероятность остановки машины непосредственно в момент проведения тестирования исчезающе мала. Больше того, даже если машина всё-таки будет остановлена, ущерб с точки зрения бизнеса будет минимальным.

Использование совместно с другими сервисами Яндекс.Облака
Сервис Yandex Instance Groups позволяет в автоматическом режиме отслеживать состояние целой группы прерываемых виртуальных машин. Он может самостоятельно создавать виртуальные машины с заданными характеристиками, поддерживать нужное количество машин в группе и перезапускать прерываемые инстансы в случае их остановки. Неважно, произошла ли принудительная остановка или прошло 24 часа с момента запуска. Важно только одно: перезапуск произойдет, если есть доступные ресурсы. Yandex Instance Groups делает работу с прерываемыми виртуальными машинами удобнее, но не может гарантировать, что в конкретной зоне доступности обязательно будут свободные мощности.

Экономические показатели
Как мы упоминали, прерываемые виртуальные машины позволяют сокращать затраты на использование вычислительных ресурсов. Внутри Яндекса мы начали работать над реализацией подобной функции ещё несколько лет назад. Чтобы разделить вычислительные задачи на гарантированно исполняемые и прерываемые, потребовались немалые инвестиции. Но всё было не зря: в итоге мы повысили уровень полезной утилизации серверной инфраструктуры с 30-40% до 70-80%.


Теперь аналогичные возможности доступны всем пользователям Яндекс.Облака по нажатию одной кнопки. Простой пример: если вы переведёте половину используемых виртуальных машин со стопроцентной загрузкой ядра в формат прерываемых, то сможете сэкономить до 35-40% бюджета.

По сниженной стоимости доступны ресурсы CPU и RAM. Дисковое пространство и IP-адреса оплачиваются по обычным тарифам. Вот что показывает простой расчёт для платформы Cascade Lake.



При желании вы можете сами сравнить стоимость использования виртуальных машин в разных режимах с помощью калькулятора. cloud.yandex.ru/prices

Надеемся, мы смогли внести немного ясности и дать несколько полезных примеров, в каких случаях можно применять прерываемые виртуальные машины, чтобы сократить расходы на вычислительные ресурсы, не теряя в качестве выполнения задач.

Инструкции по созданию прерываемых виртуальных машин и информация о тарифах здесь:

Как мы запустили в Яндекс.Облаке сервис распределённых очередей сообщений



Привет, меня зовут Василий Богонатов. Я один из тех, кто приложил руку и голову и вложил свою душу в сервис распределённых персистентных очередей сообщений Yandex Message Queue. Сервис вышел в общий доступ в конце мая, но внутри Яндекса он уже давно и активно используется в разных продуктах.

Сегодня я хочу рассказать читателям блога об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.


Что такое распределённая персистентная очередь сообщений?
Википедия определяет очередь сообщений как «программно-инженерный компонент, используемый для межпроцессного или межпотокового взаимодействия внутри одного процесса». На самом деле, это понятие несколько шире: процессы, взаимодействующие при помощи очереди, могут находиться на разных серверах и даже в разных дата-центрах.

Мы немного уточним термины.

Очередь сообщений — это хранилище, которое обеспечивает размещение и чтение данных в определённом порядке.

С очередью обычно взаимодействуют два типа сущностей:
  • писатели (producers) — отправляют сообщения в очередь;
  • читатели (consumers) — получают (читают) сообщения из очереди.
Основной сценарий для очереди: надёжно и быстро передавать сообщения от писателя к читателю. В отличие от базы данных очередь не предназначена для длительного хранения сообщений. Во многих популярных реализациях существует соответствующий параметр — «Срок хранения сообщений». Он определяет, сколько времени хранится сообщение до момента безвозвратного удаления.

Мы разобрались с понятием очереди, переходим к «распределённости» и «персистентности».
  • Распределённость в нашем случае означает наличие кластера, который хранит и обрабатывает данные и метаданные очередей, объединяя все свои узлы в единое целое с помощью вычислительной сети.
  • Персистентность подразумевает, что все сообщения в очереди записываются на диск, а писатель получает подтверждение отправки только после успешной записи.
Распределённость и персистентность не влияют на основную функциональность очереди, они обеспечивают отказоустойчивость и надёжность хранения данных. Какие виды отказов могут случиться в нашей системе, мы рассмотрим чуть позже. Однако не могу отказать в себе в удовольствии и немного раскрою карты: за всю историю существования сервиса мы не потеряли ни одного сохранённого сообщения клиента.

Подробнее
cloud.yandex.ru/blog/posts/2019/06/message-queue

Недоступность сервисов Яндекс.Облака 17 июня 2019 года



17 июня с 7:35 до 12:05 пользователи Яндекс.Облака испытывали сложности с доступом к сервисам Яндекс.Облака через консоль и API. Хотим рассказать подробнее о случившемся.

Что произошло?
В 7:35 в рамках регулярных работ по диагностике сети был перезагружен коммутатор в одной из стоек зоны доступности ru-central1-a. В 7:43 наши дежурные зафиксировали на внутренних мониторингах отсутствие доступа к сервисам через консоль или API. При этом data plane сервиса виртуальных машин Yandex Compute Cloud, сервисов управляемых баз данных и остальных сервисов работал в штатном режиме.

Дежурные инженеры определили, что причина недоступности в одном из вспомогательных компонентов внутри системы хранения метаданных Яндекс.Облака. Ошибка была локализована в 10:18, и в 11:37 сборка с исправленной ошибкой была выкачена.

В 12:05 все сервисы Яндекс.Облака вернулись в рабочее состояние.

Причины
Сервисы Яндекс.Облака хранят метаданные в высокодоступном сервисе с кодовым названием Yandex Database (YDB), который состоит из полностью независимых баз данных (по одной на каждый сервис), каждая из которых распределена между тремя зонами доступности и переживает выход любой из них из строя без потерь. Единственный компонент внутри YDB, общий для всех баз данных, — это база для хранения метаданных самой YDB и компиляции запросов к другим базам.

Несмотря на то, что этот компонент способен выдерживать большую нагрузку, в обычном режиме он обслуживает небольшое количество запросов, так как схемы баз данных сервисов меняются нечасто. В тестовых целях на базу метаданных длительное время создавалась дополнительная нагрузка в виде создания и удаления объектов схем, не приводившая к каким-либо проблемам.

При вышеупомянутых диагностических работах с сетью база метаданных кратковременно потеряла связность. Из-за программной ошибки, которая была обнаружена еще до этого, но не была еще устранена на продуктовом кластере Облака, база выслала все накопленные за время своей работы (uptime) команды на удаление объектов. Из-за существенного uptime очередь команд на удаление выросла до значительных размеров, и при фиксации на диске полученных ответов об удаленных объектах было превышено допустимое ограничение по памяти, что привело в свою очередь к рестарту базы метаданных.

База метаданных спроектирована таким образом, что после сбоя штатным образом поднимается заново на любой доступной ноде и восстанавливает свое состояние с дисков из лога изменений. Обычно рестарт базы занимает незначительное время (<1c), а time-to-live (TTL) пре-компилированных запросов был установлен в несколько минут. Но из-за программной ошибки, которая бы не проявилась без вышеописанного стечения обстоятельств, база не смогла корректно восстановить свое состояние в сроки установленного TTL.

Меры для предотвращения повторения подобной ситуации в будущем:
  • Как мы уже упомянули, программная ошибка в базе метаданных была исправлена во время устранения инцидента.
  • Мы уже увеличили TTL пре-компилированных запросов до 6 часов во всех сервисах Яндекс.Облака.
  • Мы увеличиваем долговременную тестовую нагрузку на базу метаданных. В pre-production кластерах Яндекс.Облака база метаданных будет работать с принудительными сбоями.
  • Мы реализуем шардирование базы метаданных между другими базами данных.
Мы приносим свои извинения всем пользователям, кого затронул данный инцидент. Компенсации пользователям будут начислены не позднее 28 июня 2019 года согласно соглашению об уровнях обслуживания соответствующих сервисов Яндекс.Облака при обращении в поддержку.