Как стать автором
Обновить

Комментарии 43

Круто! Тоже хочу переехать в Амазон.
Чтобы с замиранием сердца читать статусы техотдела?
Большое спасибо, что поделились опытом.
Будет интересно почитать о реализации схемы приведенной в конце статьи.

Для меня тема весьма близка — An internal error has occurred — получаю еще на этапе создания снапшота )
Да, именно при создании снэпшотов дисков рейда и получали это сообщение.

Бэкапы — наше все! ;)
Мораль — ломается всё и облако тоже, к сожалению, не панацея.
Не панацея, да.

Но облако помогает минимизировать простои и добиться максимума «девяток» в аптайме 99,9...% (100% аптайма, как известно, не бывает).
Такое облако как в Амазоне как засчитано на то что все может ломаться: и отдельные компьютеры и целые датацентры. Здесь всю в руках архитектора решения.
Выводы: Держать балансер в одном месте (желательно пару балансеров), ноды в разных, на всякий случай репликацию данных еще и в офисе.
Балансер может быть один. Восстанавливать его очень просто. И быстро.
Ну и что делать если он упадет?

Так хоть половина запросов жить будет (DNS roundrobin)
Тогда проще держать несколько физических серверов в разных ДЦ, например в 3-4 в разных странах, строить таким образом своё, персональное отказоустойчивое облако. Проблема обычно кроется в одиночном узле, точке входа, DNS, балансировщике нагрузки и так далее. Значит надо избегать одной точки входа.
У схемы с физическими серверами в разных ДЦ есть свои минусы:

— Цена.
— Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
— Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
> — Цена.
Тут согласен на 100%, физические сервера будут конечно дороже.

> — Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
Тут можно подумать, делаем два DNS-сервера ns1 и ns2 на lbnamed. Lbnamed следит за доступностью и загрузкой наших серверов в разных ДЦ и round-robin'ом отдаёт только доступные машины клиентам.

> — Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
С этим тоже согласен.
НЛО прилетело и опубликовало эту надпись здесь
Ну да, если не тот DNS закэшируется, время простоя всё равно будет измеряться сутками. Хотя скорее всего пройдёт часа 3.
> — Цена.
Скупой как известно платит дважды. Лучше переплатить немного за услуги ДЦ, чем потом гадать, как восстанавливать свою репутацию
Я сначало было удивлялся как вы сумели в разных датацентрах образ перекинуть без проблем, когда по моим сведениям это можно только в одном датацентре между разным зонами. А оказалось, что «У Амазона есть несколько Availability Zone: US East, US West, Asia Pacific (Сингапур), Asia Pacific (Токио) и EU – Ирландия».

Хочу вас слегка поправить: по всей статьей использована неправильная терминология. У амазона есть несколько _регионов_ (вот те 5 штук), которые делятся на примерно 2-3 _зоны_доступности_ в каждом регионе. Термина _датацентр_ у амазона вообще нет, потому что в этом месте things get complicated ;)
Да, действительно, Вы правы. Спасибо за уточнение! :)
Так переносить можно внутри региона или зоны доступности?
Внутри региона.
Внутри AZ можно отцеплять/прицеплять диски. Внутри региона между разными AZ — через снимок тома. Между регионами — только посредством третьих инструментов типа rsync.
Их никуда переносить вообще не надо. Они просто лежат общие на весь регион, и могут быть использованы из любой зоны доступности. Если быть точнее, то образ быть использован не может никак вообще. Из образа можно только создать том или тома. А вот том уже цепляется к инстансу (строго одному) для доступа к данным, на него можно писать и с него читать.

Для пущей ясности:
образ — snapshot
том — volume
По сути, мы мониторим всё. Кроме самого мониторинга. И этот сервер оказался в том же датацентре.

Перефразируя известную поговорку, есть архитекторы, которые географически разносят сервера и их мониторинг и есть те, кто ещё нет.
спасибо за рассказ, было очень интересно читать. У вас получилась реклама Амазона, хоть у них и простой :)
Не только и не столько Амазона (просто так получилось, что мы хостимся именно у них), сколько всей облачной концепции в целом. :)

Да, она нам нравится. :)
Вот уж не везет Амазону так не везет.
Справедливости ради стоит отметить, что не везет не только Амазону. Эта же самая авария затронула и один из ДЦ Microsoft.
Простите, а сколько у вас терабайт данных, что проблема сделать бекап в другом датацентре?

Это далеко не первая авария амазона за последнее время, а слова вида «требуется ручная работа» говорят о том, что амазон опять столкнулся с ситуацией, которую они не обкатывали в тестах.
Конкретно у нас — до терабайта, несколько сот гигабайт. Бэкап в другом датацентре сделать, конечно, можно. Только, вот, восстановление из бэкапа — плохая тема. Будет потеря последних актуальных данных. Для нас это практически недопустимо.

Что касается Амазона, то на моей памяти — это вторая подобная авария за последнее время. Предыдущая была в апреле и затронула один из регионов в Штатах.
интересно, бы ли ли серьезные фейлы у google app engine? про локальные кратковременные 'повышения латенси' и даже прекращение работы какого то сервиса или бакэнда знаю, но обычно это считанные минуты и часы.
Коммент ниже — Вам. Сорри, промахнулся.
Google App Engine — это PaaS (а Amazon EC2 — в чистом виде IaaS).

У PaaS — значительно более узкая ниша. Этот продукт рассчитан на разработчиков, а не на массового пользователя.

Как следствие — потенциально меньше «возможностей» для падений. А также — меньше возможных отзывов о падениях, если они все-таки произойдут.
Путаница с терминологией сбивает с толку. Ваши Availability Zones это на самом деле Regions, а то, что вы называете датацентрами, это как раз Availability Zones.

> Итак. Все наши серверы находились в датацентре A. Да, конечно, правильнее было бы ставить их в разных
> датацентрах (для обеспечения надежности).

Это ключевое предложение в статье :)
Наверное стоило бы разместить сервер мониторинга(вместе с ненагруженным бэкапом) в другой зоне, тогда и накладные расходы не такие большие и надёжность выше?
> Наверное стоило бы разместить сервер мониторинга(вместе с ненагруженным бэкапом) в другой зоне, тогда и накладные расходы не такие большие и надёжность выше?

Да, конечно. Выводы сделали.
Сервера оживать не начали? А то мало ли, мож Джонни пятый реинкарнировал
Про наши старые машины — не знаю. Думаю, уже и не будем их поднимать, а развернем всю инфраструктуру заново с некоторыми корректировками — это будет проще.
Ээээ… Я так понял, «Короткое замыкание» вы в детстве не смотрели?
Смотрел. Но пока не спросили, слово «оживать» воспринимал иначе. ;)
Расскажите вкратце как вы работаете с большим количеством статических файлов в кластере? Каждая нода может их писать в произвольном порядке обычными методами доступа к локальной файловой системе и всё автоматом асинхронно реплицируется? Или же код работает с какой-то файловой абстракцией которая отвечает за дублирование файлов на нодах?
Сейчас каждая нода произвольно пишет файлы на локальную файловую систему.

Каждая нода синхронизируется друг с другом с помощью csync2, утилит inotify и пары собственных скриптов.

В будущем планируется бОльшую часть статики вынести в облачное хранилище (например, в тот же Amazon S3). Тогда ничего синхронизировать уже не придется.

Поддержка основных хранилищ (Amazon S3, Google Storage, MS Azure) непосредственно в платформе «1С-Битрикс» появится в ближайшем релизе 10.5 осенью.
Да скорее бы уже.
Забавно, что сравнительно недавно был другой простой Амазона, и люди обсуждали, что стоит иметь реплику в другом регионе (region).
Первый вывод: нужно дублировать мониторинг, использовать для его целей совершенно внешние ресурсы.
Правильно сказал мой приятель: должна случаться невероятная ситуация, чтобы в одной компании, в одной комнате собралось больше одного вменяемого инженера.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий