Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 22

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 22

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 22

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 22

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 23

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 23

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 23

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /var/www/diplomtr/data/www/v5design.ru/class/class.template.php on line 23
Студия v5DESIGN - AWS в дауне: почему небеса рухнули
Студия v5DESIGN - Создание сайтов на AVE.CMS, бюджетные сайты на AVE.CMS, шаблоны для AVE.CMS, модули для AVE.CMS, дизайн AVE.CMS


Студия v5DESIGN - Создание сайтов на AVE.CMS, бюджетные сайты на AVE.CMS, шаблоны для AVE.CMS, модули для AVE.CMS, дизайн AVE.CMS
Студия v5DESIGN - Создание сайтов на AVE.CMS, бюджетные сайты на AVE.CMS, шаблоны для AVE.CMS, модули для AVE.CMS, дизайн AVE.CMS

AWS лежит 35 часов, максимально возможный аптайм за этот год упал уже ниже 99,607% — прим. пер., 24.04.2011, 23:06 МСК



AWS лежит 35 часов, максимально возможный аптайм за этот год упал уже ниже 99,607% — прим. пер., 24.04.2011, 23:06 МСК

24 апреля в 01:41 по тихоокеанскому времени произошёл серьёзный сбой в одном из дата-центров Amazon Web Services, «облака» для многих сайтов. Некоторые крупные проекты (Reddit, Quora, Foursquare) ушли в офлайн или сильно пострадали. Я уже видел кучу дезинформации с намёком на то, что проблемы пострадавших сайтов связаны только с ленью инженеров этих проектов, но в данном случае причина в другом. И вот почему.

У AWS две концепции относительно доступности: регионы (Regions) и зоны доступности (Availability Zones, AZ). Есть пять регионов: два в США (западное и восточное побережье), один в Европе (Ирландия) и два в Азии (Токио, Сингапур). В каждом регионе расположены несколько AZ, которые должны быть изолированы друг от друга и не иметь общей точки сбоя, кроме стихийного бедствия или чего-нибудь подобного масштаба.

AWS говорит, что «ставя инстансы в отдельных AZ, вы можете защитить свои приложения от сбоя в каком-то отдельном месте». Под «местом» они подразумевают «физическую независимость зон доступности друг от друга и независимую инфраструктуру». Судя по всему, это отдельные дата-центры (хотя, из описания Amazon это не очевидно — может быть, это разные этажи/комнаты в дата-центре с независимым питанием и подключением по разным каналам — прим. пер.). Они не должны рушиться одновременно друг с другом, если не случилось катастрофы, которая накрыла весь регион.

Зоны доступности также предлагают «недорогую возможность соединения с низкой задержкой между зонами доступности в том же регионе». Межрегиональный коннект, с другой стороны, идёт через открытый интернет, и относительно дорогой, медленный и ненадёжный.

Это «правила игры». Так что если вы играете по правила AWS и подняли master/slave базу данных MySQL (чтобы взять самый распространённый пример), то, по логике, вы должны поставить master и slave в одном и том же регионе, но убедиться, что они в разных зонах доступности. Вы не будете размещать их в разных регионах, иначе придётся гонять трафик по медленным и дорогим каналам между регионами, и скорее всего у вас будет больше проблем с синхронизацией баз. Вы рискуете только в том случае, если, например, ураган обрушится на восточное побережье и уничтожит дата-центр(ы), но за исключением этого всё должно быть в порядке — по крайней мере, если соблюдаются обещания AWS.

Так что, в итоге, у нас образовалась проблема. Вчера несколько зон оказались недоступными в регионе восточного побережья. AWS нарушили собственные обещания по сценарию сбоев в зонах доступности. Это значит, что у AWS есть некая общая точка сбоя (если предположить, что не случился некий абсолютно невероятный сценарий вроде одновременного физического повреждения нескольких независимых инфраструтур). Сайты, которые до сих пор в дауне, вполне корректно выполнили свои условия «правил игры», проблема в том, что AWS не следовали собственным спецификациям. Случилось это из-за некомпетентности или нечестности, или чего-то более простительного, мы просто не знаем на данный момент. Но разработчики в Quora, Foursquare и Reddit очень компетентные и будет неправильно направлять обвинения в их сторону.

Конечно, теоретически можно защититься даже от катастрофических сбоев (нескольких зон доступности), но для большинства бизнесов эти дополнительные затраты на разработку и расходы не стоят того (или могут быть даже контрпродуктивными, усложняя систему). Я уверен, что у всех сайтов, которые сейчас в дауне, сохранились бэкапы. Проблема в том, что их возврат в онлайн может стать сложным и рискованным — на практике, вам нужно всё переместить в другой регион, иначе сетевая задержка между вашими серверами будет слишком большой. На AWS это чрезвычайно сложно: на серверах разных регионов — разный набор опций, разные идентификаторы AMI, я думаю, что зарезервированные инстансы вообще нельзя перемещать между дата-центрами — в реальности, передача управления в другой регион практически невозможна. Наверное, здесь потребуется примерно столько же усилий, сколько при миграции в совершенно другое облако, что, вероятно, и является лучшим вариантом восстановления после такой катастрофы. Насколько мы знаем, Quora начала этот процесс в ту же минуту, как только случился сбой на AWS, и не завершила его до сих пор — это может занять сутки.

Так что, вкратце, винить здесь нужно исключительно AWS, которая «гарантировала» условия, которые нарушила. Ошибки случаются, но здесь именно ошибка AWS.

И это не ошибка облачного хостинга как такового. Данный случай показывает, что нужно тщательно выбирать провайдера. Я думаю, многие люди пересмотрят свой выбор в пользу AWS.

Ещё несколько мыслей:
  • Причина, по которой так много сайтов размещаются в регионе восточного побережья в том, что именно здесь AWS раньше всего выкатывает новые фичи. Он также самый дешёвый. И это, вероятно, лучший регион для обслуживания трафика (нормальная производительность для Северной Америки, сносная производительность для Европы)
  • Причиной сбоя на самом деле стали дисковые массивы EBS (Elastic Block Store), которые катастрофически проявили себя в плане надёжности с самого начала их использования. Но это уже тема совершенно другой статьи!
  • Массивы EBS могут быть только в одной зоне доступности и доступ к ним может идти только из этой зоны. Судя по всему, распределённая база данных Amazon RDS использует секретные API, позволяющие получать доступ к EBS из других зон, но эти интерфейсы не доступны никому, кроме RDS (хм… компания из Сиэттла, которая использует секретные API для получения конкурентного преимущества — звучит как-то знакомо?)



24 апреля 2011


Комментарии пользователей



Добавить комментарий | Последний комментарий