название сайта
Авторизация

Ночь в облаке

rokhmancompany 2020-12-08, 19:22 Просмотров: 173
На прошлой неделе у Amazon Web Services (AWS) произошел довольно серьезный сбой в своем регионе Восток США 1, в результате которого было отключено множество сайтов и сломаны пылесосы и дверные звонки . Произойдут сбои в работе облака, и важно понимать, как они повлияют на ваши приложения, и как правильно разрабатывать приложения для управления сбоями. Облачные вычисления предоставляют множество возможностей для создания и развертывания приложений по разным ценам. Выбор правильных вариантов зависит от навыков вашей команды, бюджета и характера вашего приложения.

Природа
сбоев в работе облака При подготовке этой статьи я исследовал ряд недавних сбоев в работе облака как в Microsoft Azure, так и в AWS. Интересно то, что по большей части каждое отключение было ограничено одним регионом в рамках одного поставщика или, в некоторых редких случаях, одной услугой в рамках поставщика. Вообще говоря, способ развертывания программного обеспечения поставщиками облачных услуг предотвращает распространение ошибок в нескольких регионах. Конечно, аппаратные сбои могут произойти, но обычно такие сбои гораздо более изолированы. Другой тип сбоя - это прекращение обслуживания. В некоторых случаях это может быть связано со сбоями в зависимых системах , но они встречаются реже. Наконец, в 2018 году потеря центра обработки данных в регионе из-за молнии уничтожила большую часть региона Azure 

Проектирование
с учетом простоев Как вы спроектируете топологию своего приложения, чтобы выдержать временный сбой, учитывая вышеупомянутые простои? Ну, обо всем по порядку: положите Visio и поговорите со своим бизнесом. Хотя проектирование для обеспечения высокой доступности и аварийного восстановления - это ИТ-функция, определение бюджета на время простоя приложений - это решение, которое должен принять бизнес.

Некоторые приложения, особенно внутренние приложения, могут терпеть значительное время простоя. Другие - например, веб-сайт, ориентированный на клиентов, - вероятно, могут терпеть простои от секунд до минут. Когда у вас будет бюджет на время простоя, вы можете начать формировать свой облачный бюджет, а затем выбрать дизайн для своего приложения.

Создание отказоустойчивого облачного приложения В
зависимости от вашего бюджета и услуг, которые вы выбрали для своих приложений, вы можете выбрать варианты по нескольким разным ценам для много-региональной поддержки. Если вы используете свой уровень базы данных на виртуальных машинах (ВМ), вы можете использовать группы доступности AlwaysOn в SQL Server, чтобы легко охватить как зоны доступности, так и регионы, чтобы ваши базы данных были широко доступны. (И AWS, и Azure) используют термин «зоны доступности» для обозначения разных физических центров обработки данных в пределах географического региона.)

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

Как я уже упоминал, дублирование инфраструктуры виртуальных машин - дорогостоящее решение, но оно позволит вам иметь несколько минут простоя в случае сбоя в регионе. Некоторые другие варианты по более низким ценам включают доставку ваших резервных копий в другой регион и планирование повторного развертывания инфраструктуры (что приводит к часам простоя) или использование такого инструмента, как Azure Site Recovery (ASR), который обеспечивает репликацию на основе инфраструктуры. Хотя ASR является хорошим решением для многих рабочих нагрузок, чрезвычайно загруженные базы данных могут привести к потере данных, поскольку процесс репликации не поддерживает SQL Server. Если вы используете решение «платформа как услуга» (PaaS), такое как База данных SQL Azure, управляемый экземпляр или Amazon RDS, ваш выбор уже, но гораздо проще реализовать.
База данных SQL Azure позволяет выполнять георепликацию до четырех различных регионов; с помощью управляемого экземпляра вы можете выполнить репликацию в один дополнительный регион. Гео-репликацию можно комбинировать с группами отработки отказа, которые предоставляют единое пространство имен (например, прослушиватель AG), чтобы обеспечить более быстрое переключение при отказе. Azure также поддерживает зоны доступности в PaaS, что отличается от георепликации и может обеспечить большее время безотказной работы в случае сбоя центра обработки данных. Кроме того, Microsoft недавно добавила возможность тестирования аварийного переключения в пределах региона, чтобы убедиться, что ваше приложение может выдержать временный сбой. Amazon RDS поддерживает многорегиональную репликацию через AWS Database Migration Service, которая использует отслеживание измененных данных в SQL Server. AWS также поддерживает развертывание группы доступности в своих собственных зонах доступности. И Azure, и AWS поддерживают георепликацию резервных копий PaaS, чтобы ваши резервные копии были доступны в случае сбоя в регионе.

Ловушка Mulitcloud
Вы заметите, что я не упоминал здесь многооблачные решения. Это было задумано. Хотя многооблачные решения могут быть хороши для приложений без сохранения состояния, таких как статическая веб-страница, сложность реализации решений для многооблачных баз данных является действительно сложной задачей, которая выходит за рамки навыков большинства организаций. Некоторые решения, такие как службы данных с поддержкой Azure Arc, пытаются упростить эту задачу, но они все еще находятся на переднем крае технологий и, вероятно, через пару лет будут легко реализованы. Кроме того, переход к решению с несколькими облаками по своей сути препятствует использованию PaaS, что может снизить выгоды, которые вы получаете от использования общедоступного облака. Сложность, присущая попыткам обработки многоуровневого аварийного переключения между облаками, означает, что вы можете легко получить больше простоев из-за своей реализации мультиоблака, чем из-за хорошо построенного решения для одного облака.

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

Чтобы поддерживать ваше приложение в случае крупных региональных сбоев, вам необходимо создать мульти-региональное решение, допускающее аварийное переключение. Вам также следует регулярно тестировать сценарии переключения при отказе, чтобы выявить любые возможные неправильные конфигурации (наиболее распространенными являются проблемы с DNS) в вашем решении. Наконец, хорошенько подумайте, прежде чем строить мульти-облачное решение; это действительно сложно, и это не то, что нужно для прихоти.




 
Читайте также
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.
Авторизация