Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Отключение AWS и как защитить себя

Когда 28 февраля этого года веб-служба Amazon (AWS) прекратила свою работу на пять часов, многие клиенты данного провайдера «облачных» услуг и сайты потеряли соеди­нение с Интернетом, в результате чего их сотрудники и клиенты остались без связи. Для компаний подобная ситуация может оказаться большой проблемой, приносящей серьезный финан­совый ущерб. Для клиентов AWS отключение продолжалось около пяти часов, и причиной была про­стая ошибка (https://aws.amazon.com/message/41926/) оператора AWS при наборе строки ввода команды в процессе технического обслуживания, как утверж­дается на сайте компании. В результате из эксплуа­тации было выведено больше серверов, чем предпо­лагалось в рамках процедуры, и это привело к сбою. Последствия этой небольшой ошибки для клиентов оказались серьезными.использование aws

Затем Amazon сообщила, что после инцидента в ее процедуры были внесены изменения, в частности усовершенствован инструмент, используемый для уда­ления серверов. Ранее применявшийся инструмент позволял выполнять весьма масштабные действия слишком быстро, в результате чего ошибка в команде могла пройти незамеченной, как говорится в заяв­лении компании: «Мы изменили инструмент, чтобы замедлить удаление ресурсов, и добавили защитные меры, благодаря которым нельзя удалить ресурсы ниже минимально необходимого порога для функ­ционирования любой подсистемы. Это исключает возможность подобных событий из-за ошибки ввода в будущем. Кроме того, мы проводим проверку других эксплуатационных инструментов, которые должны иметь аналогичные средства безопасности». Это, конечно, обнадеживает пользователей «обла­ка» и Интернета, полагающихся на многочисленные службы и сайты, размещаемые на оборудовании AWS, но какие уроки следует извлечь компаниям, чтобы их клиенты и работники не пострадали при следующем сбое?

По мнению многих ИТ-аналитиков, самое важное — заранее составить план на случай аварии.

«Компаниям настоятельно рекомендуется не скла­дывать все свои ИТ-ресурсы в одну корзину,— ко­ментирует Дэн Олдс, главный аналитики компании Gabriel Consulting Group. — Излишне полагаясь на одно «облако», вы подвергаетесь серьезной опасности». Что и произошло 28 февраля при сбое службы AWS. «Здесь все дело в избыточности. В центрах обработки данных имеются резервные системы и механизмы отра­ботки отказа для устранения аварий на уровне цен­тра обработки данных. Клиентам необходимо иметь механизмы такого же типа для ‘облачных’ рабочих нагрузок,— продолжает Олдс— В конечном итоге все, что зависит от человеческого фактора, любые про­дукты, разработанные и построенные людьми, могут дать сбой в какой-то момент, это неизбежно. И клиен­там необходимо заранее подготовить план для продол­жения работы в случае отказа одной системы, частного ‘облака*» или службы общедоступного ‘облака’». Другой аналитик, Чарльз Кинг из исследовательской фирмы Pund-IT, заметил, что даже службы повы­шенной доступности AWS не работали после аварии 28 февраля, что указывает на необходимость компани­ям подумать о собственных планах резервирования, без оглядки на финансовые затраты. «Если вам необходимо увеличить гибкость и доступ­ность, то разумно управлять приложениями и дан­ными локально или зеркалировать их не в одно публичное ‘облако’, — считает Кинг. — Дорого? Возможно. Неприемлемо? Зависит от обстоятельств. В какую сумму обойдется отключение вашей компа­нии от сети на 5 часов? Думаю, некоторые компании, пострадавшие от сбоя AWS, теперь пересматривают свои взгляды на ‘облачные’ вычисления». После аварии Кингу приходилось слышать о компа­ниях, которые создали зеркальные копии своих веб­сайтов и запускали резервные приложения на локаль­ных серверах. В результате они продолжали работу, когда другие компании, полагавшиеся исключительно на AWS, простаивали. «Если компания полностью вложилась в AWS или любую другую общедоступную ‘облачную’ службу, то она целиком зависит от поставщика», — поясняет аналитик.

По мнению Кинга, необходимо учитывать, что круп­ные авари и, подобн ые этой, происходят нечасто, но их помнят многие годы. «Не удивлюсь, если неко­торые клиенты откажутся от услуг AWS, и конку­ренты Amazon, вероятно, постараются использовать ее затруднения в своих интересах»,— заключает Кинг. С точки зрения этого аналитика, существует множество вариантов: «Microsoft Azure определенно позиционируется как передовой, надежный, удобный для бизнеса ‘облачный’ поставщик. IBM Cloud ориен­тируется на услуги корпоративного класса, с акцен­том на гибридное развертывание, в рамках которого ресурсы и службы поставщика объединяются с дан­ными и приложениями клиента». Для клиентов AWS — самый крупный поставщик «облачных» услуг на рынке, но существует ряд достой­ных альтернатив, как считает Кинг.

Дипак Мохан, аналитик исследовательской фирмы IDC, полагает, что значимость сбоя AWS 28 февраля обусловлена тем, что были нарушены чте­ние и запись в S3, одну из базовых инфраструктурных служб в AWS.

«По этой причине «облачные» приложения, чув­ствительные к простоям, должны проектироваться с учетом возможных отключений или недоступно­сти компонентов базового уровня инфраструктуры,— утверждает Мохан. — Хотя ошибки встречаются реже, в чувствительные приложения должна быть заложе­на устойчивость к недоступности инфраструктурных элементов. Это может быть сделано через зоны доступ­ности, различные регионы или инфраструктурные платформы». По мнению Мохана, в большинстве слу­чаев многосайтовая избыточность может быть органи­зована без существенных затрат и обеспечивает необ­ходимое аварийное восстановление: «По мере увеличе­ния строгости критериев затраты, естественно, будут возрастать».

В конечном итоге повторные сбои любого поставщи­ка будут отталкивать потребителей от дальнейшего использования платформы, как считает Мохан: «Это не уникальная ситуация для AWS, и в конце кон­цов потребители «облачных» услуг внедрят подходы с резервированием, типичные для истинно «облач­ных» приложений, для всех важных приложений в «облаке»».

Мы также рекомендуем строить отказоустойчивые решения с разнесением между различными облачными серверами, обращайтесь [email protected]

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.