Кратко:
- Кластеры: использование управляемой БД в Yandex Cloud начинается с создания кластера.
- Масштабируемость: управляемые БД решают проблему с помощью масштабирования.
- Доступность и отказоустойчивость: сервисы управляемых БД помогут улучшить доступность приложения или сайта.
- Кластеры высокой доступности: кластер можно настроить так, что любой хост автоматически станет мастером.
- Отказоустойчивость: кластеры отказоустойчивы, если имеют избыточные ресурсы и размещены в разных зонах доступности.
- Выбор системы: зависит от приоритетов: высокодоступная или отказоустойчивая.
Кластеры, масштабируемость, доступность и отказоустойчивость
На ближайших уроках вы научитесь работать с БД в облаке: создавать, записывать, запрашивать и переносить данные между ними, создавать резервные копии и восстанавливаться из них.
Чтобы приступить к практике, стоит понимать несколько основных концепций, с которыми вы будете иметь дело на протяжении всего этого курса. Это кластеры, масштабирование, доступность и отказоустойчивость.
Кластеры
Использование управляемой БД в Yandex Cloud начинается с создания кластера. Кластер — это одна или несколько виртуальных машин (или хостов), где разворачивается БД.
Настройки кластера для БД мы подробно разберём на практических уроках. Здесь же остановимся на нескольких общих моментах.
При создании кластера вы увидите в интерфейсе настройки по умолчанию. Они позволяют быстро начать работу, не выставляя вручную каждый параметр. К тому же большинство настроек (например число ядер процессора, объём памяти и размер дискового пространства) можно изменить позже. Тогда сервис автоматически поочерёдно отключит хосты, применит изменения и включит хосты обратно. БД при этом будет недолго доступна только для чтения.
Значения некоторых настроек определяются размером кластера и зависят от числа ядер или объёма оперативной памяти. Например, лимит
max_connection (максимальное число соединений с БД) в управляемой БД PostgreSQL — 200 соединений на один виртуальный процессор (vCPU).Единственный параметр, который не стоит пропускать при создании кластера, — это настройка Окружение. Она глобально влияет на кластер, и ее нельзя будет изменить.
Окружение бывает
PRESTABLE или PRODUCTION. Ключевое различие в том, как обновляется программное обеспечение, управляющее БД.Мажорные и минорные обновления системы управления базой данных (СУБД), а также обновления, касающиеся работы сервиса управляемых БД, сначала попадают в окружение
PRESTABLE. В нём обновления не гарантируют обратную совместимость и иногда содержат ошибки. Поэтому используйте PRESTABLE для сред разработки и тестирования, чтобы обкатывать новые приложения и функциональности.В окружение
PRODUCTION попадают только проверенные и стабильные обновления. Выбирайте его для той версии приложения, которая полноценно запущена и доступна пользователям.Масштабируемость
Управляемые БД помогают оптимально использовать вычислительные и дисковые ресурсы виртуальных машин.
Допустим, вы планируете работу интернет-магазина подарков в декабре и январе. В предпраздничные дни поток посетителей вырастет в десятки раз, а в первые январские дни упадет. Если сервер с БД магазина не справится с наплывом покупателей — они, раздражённые подвисаниями или сбоями, наверняка перейдут к конкурентам. В то же время постоянно держать ресурсы про запас невыгодно — после праздников посетителей будет очень мало.
Управляемые БД решают эту проблему с помощью масштабирования, изменяя количество ресурсов с учётом реальной или ожидаемой нагрузки.
БД можно масштабировать двумя способами: вертикально и горизонтально.
При вертикальном масштабировании меняется количество ядер и объём жёсткого диска на хосте, где работает база данных. Например, вы можете поменять тип хоста с
s2.medium (8 ядер и 32 ГБ оперативной памяти) на s2.x4large (40 ядер и 160 ГБ оперативной памяти) и увеличить объём диска на 50 ГБ. Такая операция занимает всего несколько минут. У этого способа, однако, есть предел: очередное увеличение станет или слишком дорогим, или технически невозможным.При горизонтальном масштабировании меняется число хостов, между которыми распределена нагрузка на БД. Такой способ поддерживают не все СУБД, но если эта возможность есть, то с технической точки зрения уже неважно, сколько хостов вы добавляете.
Производительность и объём диска одного хоста бывают небольшими, но каждый хост обрабатывает лишь часть общей нагрузки и хранит часть общих данных. Такая система может быть эффективнее, чем один большой и мощный сервер.
Вернёмся к примеру с интернет-магазином. Используя управляемую БД, при резком наплыве посетителей вы добавите ресурсы — и система продолжит работать стабильно и быстро. А когда пиковые нагрузки пройдут, вы так же легко остановите или удалите ненужные хосты и уменьшите расходы.
Доступность и отказоустойчивость
Компания, владеющая интернет-магазином, заинтересована в том, чтобы сайт работал постоянно, даже если оборудование выходит из строя. Технически говоря, компанию интересуют высокая доступность и отказоустойчивость.
Доступность — способность работать беспрерывно — обычно измеряется в процентах и вычисляется как часть времени, когда система полноценно функционировала. Например, доступность 99,99% означает, что БД может не отвечать на запросы лишь 0,01% времени (за 30-дневный месяц это 4 минуты 19 секунд).
Сервисы управляемых БД помогут вам без особых усилий улучшить доступность приложения или сайта. Когда вы разворачиваете БД на одном из хостов кластера, сервис автоматически её реплицирует: создает копии (реплики) основной базы (мастера) на остальных хостах и синхронизирует данные между мастером и репликами.
Если хост выйдет из строя, система продолжит работать, и данные не потеряются. Вы заметите сбой только на мастере: до его восстановления БД будет обрабатывать лишь запросы на чтение.
Более того, вам не придется останавливать кластер, чтобы обновить операционную систему или СУБД. Сервис выполнит все обновления незаметно для вас, поочерёдно отключая хосты и распределяя нагрузку между ними.
Кластер можно настроить так, что любой хост автоматически станет мастером, если с первоначальным мастером возникнут проблемы. Такая группа хостов называется кластером высокой доступности (high-availability cluster).
Но что делать, если даже короткий сбой в работе приложения может привести к очень серьёзным последствиям (авариям, крупному финансовому ущербу)? В этом случае нужна 100%-я доступность, иными словами — отказоустойчивость.
Отказоустойчивая система продолжает работать, даже если любой компонент выходит из строя. Это достигается за счёт большой избыточности ресурсов. Чтобы сделать кластер отказоустойчивым, мы можем увеличить в нём число хостов и разнести их по разным зонам доступности. Это поможет избежать отказов на уровне дата-центров.
Какую систему строить: высокодоступную или отказоустойчивую? Это зависит от ваших приоритетов. В первом случае мы допускаем, что система сломается и недолгое время будет недоступна. Во втором — делаем всё возможное, чтобы система работала, даже если какой-то из её элементов выйдет из строя. В том числе добавляем избыточные ресурсы и тратим на них немалые деньги (каждый дополнительный хост стоит столько же, сколько хост-мастер). Решайте сами, за какие проценты доступности и сколько вы готовы платить.