Общие рекомендации по созданию отказоустойчивых приложений

Общие рекомендации по созданию отказоустойчивых приложений

  1. Используйте доменные имена для общения узлов вашего приложения между собой. Таким образом вы не будете привязаны к IP-адресам.
  2. По возможности используйте управление вашей инфраструктурой через API (подробнее - в этой статье https://mcs.mail.ru/help/iaas-api/openstack-api).
  3. По возможности управляйте своей инфраструктурой как кодом (Infrastructure as Code, IaC) - используя популярные средства управления конфигурациями, такими как Ansible или Terraform.
  4. В сетях MCS используется технология VxLAN. Для корректной работы некоторых приложения необходимо выставить в настройках сетевых адаптеров значение MTU равным 1460.
  5. Используйте разные приватные сети для разных приложений в рамках одного проекта или используйте для каждого приложения собственный проект.
  6. Используйте встроенные группы безопасности. Открывайте только те порты и протоколы, которые необходимы для работы и администрирования приложений (подробнее - в этой статье https://mcs.mail.ru/help/disks-and-images/filestorage).
  7. Планируйте свое приложение так, чтобы любой узел мог горизонтально масштабироваться. Не допускайте наличия узлов, которые возможно масштабировать только вертикально.
  8. Используйте резервное копирование для всех узлов своего приложения (подробнее - в этой статье https://mcs.mail.ru/help/cloud-backups).
  9. Выставляйте в интернет только front-end  своих приложений, не делайте доступ на все узлы вашего приложения из интернета.
  10. Используйте защищенный VPN IPSec для связанности ваших локальных ресурсов с ресурсами в облаке (подробнее - в этой статье - https://mcs.mail.ru/help/network/vpn).
  11. Используйте S3-хранилища (например, Cloud Storage) для долгосрочного хранения больших объемов информации или статического контента.
  12. Используйте гео-раcпределенное хранилище для высокой доступности ваших данных. Учитывайте, что гео-распределенное хранилище имеет более высокий latency, и не подходит для решений, требующих низкий latency дисковой подсистемы - например БД.
  13. Используйте тот тип дисков, который необходим для вашего профиля нагрузки (подробнее - в этой статье https://mcs.mail.ru/help/about-bigdata/specifications-bigdata#section-0).
  14. Используйте встроенное сетевое отказоустойчивое хранилище в качестве файлового хранилища (подробнее - в этой статье https://mcs.mail.ru/help/disks-and-images/filestorage).
  15. Используйте auto-scaling (автомасштабирование) для отработки пиковых нагрузок на ваше приложение. Подробнее - в этой статье https://mcs.mail.ru/help/kubernetes/scaling.
  16. Настройте мониторинг вашего приложения. Про мониторинг можно прочитать тут https://mcs.mail.ru/help/kubernetes/monitoring.
  17. Используйте документацию https://mcs.mail.ru/help, или напишите нам в форму обратной связи, если у вас остались вопросы.

Зоны доступности

Для создания отказоустойчивого, географически распределенного приложения можно использовать размещение серверов приложения в разных зонах доступности. Зона доступности в MCS соответствует ЦОДу уровня Tier3. При запуске экземпляров виртуальных машин для вашего приложения вы можете выбрать соответствующую зону доступности. Таким образом вы повысите отказоустойчивость на случай катастроф. Рекомендуемое количество нод приложения = 2N, разнесенных по разным зонам доступности.

Для балансировки нагрузки между нодами вашего приложения   рекомендуется использовать Load Balancing. Вы можете использовать встроенный балансировщик нагрузки - инструкция по его настройке представлена в этой статье https://mcs.mail.ru/help/network/balancers.

Отказоустойчивость баз данных

Для создания отказоустойчивой базы данных не рекомендуется использовать single-node. Режим single-node подходит только для dev и test сред. 

Используйте базы данных в конфигурации Master-Slave или кластерной конфигурации. Разнесите разные экземпляры баз данных по разным зонам доступности и настройте репликацию, используя стандартные средства текущей БД. Используйте механизмы консистентного бекапа для возможности восстановления данных. Также вы можете использовать MCS DBaaS - этот сервис имеет встроенные механизмы high-availability и инкрементальных консистентных резервных копий.

Выбор типа блочных устройств

Создание root-диска виртуальной машины.

При создании вашей виртуальной машины вы выбираете, с каким типом дисков запустить ВМ. На этом этапе вы выбираете тип диска для корневого диска ВМ, на котором находится ОС (Диск С: в терминах Windows, /de/vda в терминах Linux. 

Не имеет смысла создавать большой root-диск ОС, или выбирать очень быстрый тип диска, если для этого нет специальных требований вашего приложения, так как данные обычно пишутся на отдельный диск (блочное устройство). 

Создание блочного устройства

В разделе "Диски" портала MCS есть возможность создать блочное устройство, выбрав его тип, регион и размер. Обратите внимание, что Регион (зона доступности) должна совпадать с зоной доступности вашей ВМ во избежание дополнительных сетевых задержек (latency). 

Размер блочного устройства может быть любым для типа дисков «Сетевой». Для типа дисков High-IOPS SSD ограничение размера составляет 2TB. Если вам необходим бóльший размер блочного устройства на данном типе дисков, то необходимо создать несколько блочных устройств, с необходимым суммарным объемом, подать на ВМ и собрать, например, LVM. 

Типы дисков отличаются аппаратной конфигурацией, количеством IOPS и latency. Выбирайте тот тип дисков, который необходим для вашего приложения. Так, например, не стоит выбирать тип дисков HDD для баз данных или выбирать High-IOPS SSD для мало нагруженных или тестовых сред. Имеются следующие типы дисков:

  • HighIOPS SSD -  представляет из себя массив дисков, собранных в RAID10 и отдаются по протоколу iSCSI. Подходят для высоконагруженных БД и приложений, требующий низких latency и высоких показателей IOPS.
  • Сетевой SSD – представляет из себя программно-определяемое хранилище, на базе ПО Ceph с использованием ssd-дисков. Подходит для большинства приложений и не сильно нагруженных баз данных. 
  • Сетевой SSD с гео-репликацией – обладает теми же характеристиками по IOPS что и сетевой ssd, гарантировано хранит копии данных в разных ЦОДах, за счет чего у данного типа дисков выше latency. Подходит для задач, когда доступность данных online важнее скорости обращения к ним. 
  • Сетевой HDD - представляет из себя программно-определяемое хранилище, на базе ПО Ceph с использованием hdd-дисков. Подходит для дешевого хранения больших объемов данных, легких приложений, тестирования и разработки.
  • Сетевой HDD с гео-репликацией - обладает теми же характеристиками по IOPS что и сетевой hdd, гарантировано хранит копии данных в разных ЦОДах, за счет чего у данного типа дисков выше latency. Подходит для задач, когда доступность данных online важнее скорости обращения к ним. 

Расчет Quality of Service для дисков

Для расчета кол-ва квоты на IOPS дисков необходимо воспользоваться следующей таблицей:

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

Например:
При выборе типа диска «Сетевой HDD» объемом 1-150GB вы получите минимальные квоты на read/write iops, при размере диска 500GB вы получите 500 read/write iops, при размере 1TB вы получите 1000 iops read и 800 iops write.
При выборе типа дисков «HighIOPS» объемом 1-200GB вы получите минимальные квоты на read/write iops, при размере 1TB – 30k iops read, 25k iops write.

При тестировании дисков учитывайте размер блока в KB, согласно следующей таблице:

Типы проводимого тестирования

Результат тестирования (Количество IOPS)

Чтение/запись блоками по 4 кб в 32 потока

В соответствии со значениями SLA

Чтение/запись блоками по 8 кб в 32 потока

не менее 75% от SLA

Чтение/запись  по 16 кб в 32 потока

не менее 50% от SLA

Использование  Load Balancing as a Service

Для повышения отказоустойчивости и гибкой масштабируемости вашего сервиса рекомендуется использовать балансировку нагрузки между вашими экземплярами ВМ (например, между front-end приложениями). 

При выборе ВМ, между которыми вы хотите балансировать трафик, убедитесь, что все экземпляры ВМ не находятся в одной зоне доступности. Обратите внимание, что load balancer должен находиться в той же сети, что и ваши ВМ.

Вы можете использовать наш отказоустойчивый сервис LBaaS - подробную инструкцию по настройке Load Balancing вы найдете в этой статье https://mcs.mail.ru/help/network/balancers.

После настройки LBaaS рекомендуется провести нагрузочное тестирование, а также тестирование отключения некоторых нод вашего приложения.

Обратите внимание, что для некоторых сервисов MCS мы создаем load balancer по умолчанию.