Облачное хранение данных не отменяет необходимость их резервного копирования. Об этом Агентству городских новостей «Москва» сообщила технический директор Postgres Professional Юлия Рынденкова.
«Главный вывод из подобных инцидентов – облако само по себе не отменяет необходимость независимого резервного копирования и аварийного восстановления. Существует опасное заблуждение: «Зачем нам собственные бэкапы, если мы арендуем мощности в облаке или храним данные в S3?». Ни одно, даже самое надежное публичное облако, не является абсолютной гарантией при физическом разрушении инфраструктуры площадки или сбое единого контура управления», – сказала Рынденкова.
По ее словам, чтобы избежать катастрофических потерь, архитектура данных должна строиться по принципу нулевого доверия к единой точке отказа. Критически важные базы данных должны синхронно или полусинхронно реплицироваться между независимыми географическими зонами, удаленными друг от друга на сотни километров. Также критично важно использовать специализированные инструменты бэкапирования.
«Резервные копии баз данных нельзя складывать в тот же регион или даже ту же облачную экосистему. <...> Важно не только делать бэкапы, но и регулярно проверять их работоспособность и целостность данных, чтобы в критических ситуациях минимизировать риски сбоев при восстановлении. Кроме того, в компании должен быть разработанный и актуальный план аварийного восстановления (Disaster Recovery Plan) на случай возможных сбоев, определяющий четкий порядок действий команды при отказе инфраструктуры», – добавила Рынденкова.
Она отметила, что физическое повреждение инфраструктуры дата-центра – это всегда нештатная ситуация максимального уровня критичности, которая тестирует на прочность не только конкретную площадку, но и общую архитектуру отказоустойчивости сервисов.
«Оценивать масштаб урона по внешним сбоям прикладных систем некорректно: когда ЦОД внезапно отключается от сети и питания, нагрузка лавинообразно перераспределяется на уцелевшие площадки. Деградация сервисов у конечных пользователей чаще связана с каскадными перегрузками оставшихся вычислительных узлов, сетевыми задержками при перестроении маршрутов и рассинхронизацией состояний баз данных, а не с безвозвратной утратой вычислителей. Подобная реакция платформ естественна в первые часы после резкой потери крупной зоны доступности», – пояснила Рынденкова.
В подобных инцидентах восстановление разделяется на два параллельных контура: восстановление доступности сервисов и восстановление физической инфраструктуры.
«При наличии геораспределенной архитектуры и настроенных сценариев аварийного переключения сервисы возвращаются к штатной работе за часы. Основное время уходит на валидацию консистентности данных и балансировку нагрузок между уцелевшими ЦОД. Ремонт строительных конструкций, силовых подстанций, систем охлаждения и замена пострадавших серверных стоек могут занять от нескольких недель до месяцев. Все это время нагрузка будет удерживаться резервными мощностями», – заключила Рынденкова.
Ранее Агентство «Москва» сообщало, что в России могут вырасти цены на облачные услуги, сильнее всего его могут почувствовать арендаторы большого объема серверных мощностей.