Комментарии 43
Круто! Тоже хочу переехать в Амазон.
Большое спасибо, что поделились опытом.
Будет интересно почитать о реализации схемы приведенной в конце статьи.
Для меня тема весьма близка — An internal error has occurred — получаю еще на этапе создания снапшота )
Будет интересно почитать о реализации схемы приведенной в конце статьи.
Для меня тема весьма близка — An internal error has occurred — получаю еще на этапе создания снапшота )
Да, именно при создании снэпшотов дисков рейда и получали это сообщение.
Бэкапы — наше все! ;)
Бэкапы — наше все! ;)
Мораль — ломается всё и облако тоже, к сожалению, не панацея.
Не панацея, да.
Но облако помогает минимизировать простои и добиться максимума «девяток» в аптайме 99,9...% (100% аптайма, как известно, не бывает).
Но облако помогает минимизировать простои и добиться максимума «девяток» в аптайме 99,9...% (100% аптайма, как известно, не бывает).
Такое облако как в Амазоне как засчитано на то что все может ломаться: и отдельные компьютеры и целые датацентры. Здесь всю в руках архитектора решения.
Выводы: Держать балансер в одном месте (желательно пару балансеров), ноды в разных, на всякий случай репликацию данных еще и в офисе.
Балансер может быть один. Восстанавливать его очень просто. И быстро.
Ну и что делать если он упадет?
Так хоть половина запросов жить будет (DNS roundrobin)
Так хоть половина запросов жить будет (DNS roundrobin)
Тогда проще держать несколько физических серверов в разных ДЦ, например в 3-4 в разных странах, строить таким образом своё, персональное отказоустойчивое облако. Проблема обычно кроется в одиночном узле, точке входа, DNS, балансировщике нагрузки и так далее. Значит надо избегать одной точки входа.
У схемы с физическими серверами в разных ДЦ есть свои минусы:
— Цена.
— Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
— Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
— Цена.
— Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
— Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
> — Цена.
Тут согласен на 100%, физические сервера будут конечно дороже.
> — Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
Тут можно подумать, делаем два DNS-сервера ns1 и ns2 на lbnamed. Lbnamed следит за доступностью и загрузкой наших серверов в разных ДЦ и round-robin'ом отдаёт только доступные машины клиентам.
> — Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
С этим тоже согласен.
Тут согласен на 100%, физические сервера будут конечно дороже.
> — Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
Тут можно подумать, делаем два DNS-сервера ns1 и ns2 на lbnamed. Lbnamed следит за доступностью и загрузкой наших серверов в разных ДЦ и round-robin'ом отдаёт только доступные машины клиентам.
> — Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
С этим тоже согласен.
> — Цена.
Скупой как известно платит дважды. Лучше переплатить немного за услуги ДЦ, чем потом гадать, как восстанавливать свою репутацию
Скупой как известно платит дважды. Лучше переплатить немного за услуги ДЦ, чем потом гадать, как восстанавливать свою репутацию
Я сначало было удивлялся как вы сумели в разных датацентрах образ перекинуть без проблем, когда по моим сведениям это можно только в одном датацентре между разным зонами. А оказалось, что «У Амазона есть несколько Availability Zone: US East, US West, Asia Pacific (Сингапур), Asia Pacific (Токио) и EU – Ирландия».
Хочу вас слегка поправить: по всей статьей использована неправильная терминология. У амазона есть несколько _регионов_ (вот те 5 штук), которые делятся на примерно 2-3 _зоны_доступности_ в каждом регионе. Термина _датацентр_ у амазона вообще нет, потому что в этом месте things get complicated ;)
Хочу вас слегка поправить: по всей статьей использована неправильная терминология. У амазона есть несколько _регионов_ (вот те 5 штук), которые делятся на примерно 2-3 _зоны_доступности_ в каждом регионе. Термина _датацентр_ у амазона вообще нет, потому что в этом месте things get complicated ;)
Да, действительно, Вы правы. Спасибо за уточнение! :)
Так переносить можно внутри региона или зоны доступности?
Внутри региона.
Внутри AZ можно отцеплять/прицеплять диски. Внутри региона между разными AZ — через снимок тома. Между регионами — только посредством третьих инструментов типа rsync.
Их никуда переносить вообще не надо. Они просто лежат общие на весь регион, и могут быть использованы из любой зоны доступности. Если быть точнее, то образ быть использован не может никак вообще. Из образа можно только создать том или тома. А вот том уже цепляется к инстансу (строго одному) для доступа к данным, на него можно писать и с него читать.
Для пущей ясности:
образ — snapshot
том — volume
Для пущей ясности:
образ — snapshot
том — volume
По сути, мы мониторим всё. Кроме самого мониторинга. И этот сервер оказался в том же датацентре.
Перефразируя известную поговорку, есть архитекторы, которые географически разносят сервера и их мониторинг и есть те, кто ещё нет.
спасибо за рассказ, было очень интересно читать. У вас получилась реклама Амазона, хоть у них и простой :)
Вот уж не везет Амазону так не везет.
Простите, а сколько у вас терабайт данных, что проблема сделать бекап в другом датацентре?
Это далеко не первая авария амазона за последнее время, а слова вида «требуется ручная работа» говорят о том, что амазон опять столкнулся с ситуацией, которую они не обкатывали в тестах.
Это далеко не первая авария амазона за последнее время, а слова вида «требуется ручная работа» говорят о том, что амазон опять столкнулся с ситуацией, которую они не обкатывали в тестах.
Конкретно у нас — до терабайта, несколько сот гигабайт. Бэкап в другом датацентре сделать, конечно, можно. Только, вот, восстановление из бэкапа — плохая тема. Будет потеря последних актуальных данных. Для нас это практически недопустимо.
Что касается Амазона, то на моей памяти — это вторая подобная авария за последнее время. Предыдущая была в апреле и затронула один из регионов в Штатах.
Что касается Амазона, то на моей памяти — это вторая подобная авария за последнее время. Предыдущая была в апреле и затронула один из регионов в Штатах.
интересно, бы ли ли серьезные фейлы у google app engine? про локальные кратковременные 'повышения латенси' и даже прекращение работы какого то сервиса или бакэнда знаю, но обычно это считанные минуты и часы.
Google App Engine — это PaaS (а Amazon EC2 — в чистом виде IaaS).
У PaaS — значительно более узкая ниша. Этот продукт рассчитан на разработчиков, а не на массового пользователя.
Как следствие — потенциально меньше «возможностей» для падений. А также — меньше возможных отзывов о падениях, если они все-таки произойдут.
У PaaS — значительно более узкая ниша. Этот продукт рассчитан на разработчиков, а не на массового пользователя.
Как следствие — потенциально меньше «возможностей» для падений. А также — меньше возможных отзывов о падениях, если они все-таки произойдут.
Путаница с терминологией сбивает с толку. Ваши Availability Zones это на самом деле Regions, а то, что вы называете датацентрами, это как раз Availability Zones.
> Итак. Все наши серверы находились в датацентре A. Да, конечно, правильнее было бы ставить их в разных
> датацентрах (для обеспечения надежности).
Это ключевое предложение в статье :)
Наверное стоило бы разместить сервер мониторинга(вместе с ненагруженным бэкапом) в другой зоне, тогда и накладные расходы не такие большие и надёжность выше?
> Итак. Все наши серверы находились в датацентре A. Да, конечно, правильнее было бы ставить их в разных
> датацентрах (для обеспечения надежности).
Это ключевое предложение в статье :)
Наверное стоило бы разместить сервер мониторинга(вместе с ненагруженным бэкапом) в другой зоне, тогда и накладные расходы не такие большие и надёжность выше?
Сервера оживать не начали? А то мало ли, мож Джонни пятый реинкарнировал
Расскажите вкратце как вы работаете с большим количеством статических файлов в кластере? Каждая нода может их писать в произвольном порядке обычными методами доступа к локальной файловой системе и всё автоматом асинхронно реплицируется? Или же код работает с какой-то файловой абстракцией которая отвечает за дублирование файлов на нодах?
Сейчас каждая нода произвольно пишет файлы на локальную файловую систему.
Каждая нода синхронизируется друг с другом с помощью csync2, утилит inotify и пары собственных скриптов.
В будущем планируется бОльшую часть статики вынести в облачное хранилище (например, в тот же Amazon S3). Тогда ничего синхронизировать уже не придется.
Поддержка основных хранилищ (Amazon S3, Google Storage, MS Azure) непосредственно в платформе «1С-Битрикс» появится в ближайшем релизе 10.5 осенью.
Каждая нода синхронизируется друг с другом с помощью csync2, утилит inotify и пары собственных скриптов.
В будущем планируется бОльшую часть статики вынести в облачное хранилище (например, в тот же Amazon S3). Тогда ничего синхронизировать уже не придется.
Поддержка основных хранилищ (Amazon S3, Google Storage, MS Azure) непосредственно в платформе «1С-Битрикс» появится в ближайшем релизе 10.5 осенью.
Забавно, что сравнительно недавно был другой простой Амазона, и люди обсуждали, что стоит иметь реплику в другом регионе (region).
Первый вывод: нужно дублировать мониторинг, использовать для его целей совершенно внешние ресурсы.
Правильно сказал мой приятель: должна случаться невероятная ситуация, чтобы в одной компании, в одной комнате собралось больше одного вменяемого инженера.
Правильно сказал мой приятель: должна случаться невероятная ситуация, чтобы в одной компании, в одной комнате собралось больше одного вменяемого инженера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рассказ о том, как молния «убила» облако Amazon