Подписка на RSS

7 секретов успешного масштабирования с SCALR (на Amazon) от Sebastian Stadil

Это часть интервью с Sebastian Stadil, основателем Scalr, дешевой опенсорс-версии RightScale. Scalr заботится об инфраструктурах всех web-сайтов, находящихся на Amazon (и других облаках), так что вам этого делать не приходится.

Я впервые встретил Sebartian на одном из собраний группы Valley Cloud Computing Group, которую он основал. Собрания начались в крошечных офисах Intalio, где Sebastian работал с этими новыми штуками от Amazon для создания фермы автоматически масштабирующихся серверов на EC2. Я хорошо помню, как Sebastian встречал каждого в дверях с улыбкой и рукопожатием, заставляя нас чувствовать себя как дома. Позже я посетил его занятия по использованию AWS. Я думаю, он разобрался со всеми этими облачными вещами и решил организовать Scalr.

Мне очень жаль, что название «Amazon» не начинается с буквы ‘S’ – тогда бы получилось просто эпическое название поста.

Знакомство

В этом разделе – ответы Sebastian на общие вопросы о Scalr.

Что такое Scalr
Scalr – это тот самый парень, которого вы просите помочь разобраться с серверами: Scalr помогает вам создавать масштабируемую инфраструктуру и управлять ей.

Когда ты начал?
Scalr выпущена в свет под GPL лицензией в апреле 2008, так что в следующем месяце мы празднуем двухлетнюю годовщину с Scalr 2.0!

Что заставило тебя покинуть старую работу и начать заниматься Scalr?
Потому что очень сложно построить правильную инфраструктуру! И масштабирование так дорого обходится!

Твой продукт развивался со временем?
Сначала он использовал только EC2 и обходные пути из-за отсутствия EBS. А сейчас это полностью функциональная система, использующая последние фичи Amazon, такие как RDS и ELB, для масштабирования и управления всем для вас.

Можешь сравнить с RightScale и предложениями Amazon?
Представляйте Scalr как опенсорс RightScale, фокусирующийся только на масштабировании web-приложений. Amazon почти не предлагает автоматизации и не помогает вам создавать масштабируемую архитектуру. Если у есть хотя бы маленький шанс, что ваш проект вырастет, ознакомьтесь с нашей системой.

Как думешь, к чему движутся все эти облачные штуки?
Я вижу некоторые зарождающиеся перспективы в управлении гибридным облаком, но очень надеюсь, что за 3 года все новые приложения будут готовы к выкладыванию в интертрубы в 1 клик, самоуправляемы и готовы к масштабированию. Мы добавляем поддержку для всех остальных облачных платформ.

7 секретов для успешного масштабирования с Scalr

Я подумал, что Sebastian за много лет приобрел большой опыт работы с AWS, и ему должно быть известно множество трюков и ловушек. Поэтому я попросил рассказать его, о каких главных проблемах следует помнить, когда работаешь с Amazon, и затем объяснить, как Scalr помогает их решать. Вот ответы Sebastian:

Не задавайте четко адреса.
Вещи меняются быстро в облаке, особенно IP адреса. Адрес базы данных, который у вас есть сегодня, может измениться завтра или на следующей неделе. Это может произойти случайно из-за остановки или запуска сущности EC2 или предсказуемо, когда вычисления и данные переезжают по разным пулам ресурсов – например, с EC2 на Rackspace Cloud. Elastic IPs — сервис Amazon для привязки IP к любому серверу — решает эту проблему до тех пор, пока вы продолжаете использовать сервисы Amazon. Но вы не можете назначить его не EC2 серверу, поэтому вы не можете использовать это за пределами AWS.

Проблема в данном случае заключается в том, что когда вы жестко задаете адрес базы данных как IP адрес в вашем приложении и этот IP адрес меняется, то ваше приложение будет отправлять запросы и данные в никуда — ничего хорошего, согласитесь. Для того чтобы справиться с этим, хорошим решением будет определять адрес назначения перед отправкой на него данных — DNS как раз придумали для этого.

Мы все это упростили в Scalr. Scalr хранит обновленный список IP адресов для каждой сущности и названия сервера в форме записей DNS на кластере серверов имен. Когда вы отправляете запрос к базе данных db.example.com, клиент ищет IP адрес для этого имени сервера в записях DNS для этой зоны и кэширует все это до тех пор, пока не истечет TTL.

Переносите вычисления в Rackspace Cloud? Scalr добавит записи для вашей новой базы данных на Rackspace и удалит ссылки на IP адреса EC2.

Масштабирование чтения-записи прошло долгий путь
Принимая во внимание все сегодняшние разговоры о шардинге и noSQL, легко оценить, как много вы сможете сделать с кластером мастер-слэйв репликаций.

Кластер мастер-слэйв репликаций – это набор множеств баз данных, которые синхронизируют данные в одном направлении. Мастер-база данных – это хранитель всех данных, и она единственная, в которую вы записываете: INSERT, DELETE и UPDATE. Слэйв-база данных реплицирует данные от мастера и хранит их копию. Из нее вы производите чтение: SELECT. Это разделение освобождает ресурсы в мастере, которые часто ограничены возможностями CPU, и позволяет вам производить JOIN без уничтожения всей производительности, так как обрабатывает эту операцию слэйв, а не мастер.

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

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

Распределять CRON задания очень тяжело
Посмотрите на то, как масштабируются инстансы с cron заданиями на них. Cron задания не проектировались для облака. Если промасштабировать образ машины, содержащей cron задание на 20 инстансов, то получится, что ваше cron задание будет выполняться в 20 раз чаще.

Это еще ничего, если границы вашего cron задания ограничены сами инстансом, но если границы распространяются дальше, то у вас появится большая проблема. И если у вас будет только одна машина, которая запускает cron задание, то вы рискуете, что задание не выполнится, если эта машина упадет.

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

Apache Software Foundation имеет изящную утилиту для распределенного сервиса блокировок. Она называется Zookeeper. Эта утилита является основанием распределенной системы cron задач от Scalr, поэтому пользователи могут настраивать периодическое выполнение скриптов, таких как cron задачи, и риска того, что задание будет выполнено несколько раз или не выполнено вообще, не будет.

Разработка и продакшн должны быть близнецами.
Различия между окружениями разработки и продакшена могут вызвать сбои при переводе продукта из одного в другое. Что-нибудь незначительное – например, различные размеры инстанса, – может вызвать неполадки, особенно на EC2, где маленькие инстансы 32-битные, а большие 64-битные.

Традиционно компании запускают разработку и QA на выделенных серверах. Так как они используются непостоянно, например, пару недель до релиза, компании обычно экономят, покупая только по одному серверу каждого типа — это особенно верно, когда ваша архитектура требует программы с несвободными лицензиями. Брать дополнительные лицензии на Oracle ради нескольких недель в году может быть очень расточительным поступком.

В облаке все обстоит иначе. Так как ты платишь только за то, что взял, вы можете можете получить сервера на ограниченный период, пока вы их используете. Если вы используете Scalr, то все еще проще: просто клонируйе вашу ферму продакшн серверов и называйте их QA. Используйте их 8 часов в понедельник и затем уже выключайте утром во вторник. У вас будет идеальная копия вашего продакшн окружения (та же архитектура, системы и данные), дневная цена часто ниже цены запуска.

А еще сделайте снэпшот вашей базы данных и запускайте Dev и QA с теми же данными, как в продакшене. Используйте Apache Bench и вы сможете получить даже ту же самую нагрузку.

Учитесь у комьюнити
Достаточно сложно оставаться в курсе всех последних изменений и трюков с инфраструктурой, от Cassandra и Nencached до Varnish и nginx. Я не могу даже представить, сколько нужно времени, чтобы изучить все с нуля

Пока существует множество фреймворков (таких, как построенный нами проект Scalr), и платформ (Heroku и Google App Engine), которые либо упрощают масштабирование, либо абстрагируют все, полезно иметь немного знаний о более нижнем уровне — механике всего этого. Я понял, что чтение OSI модели компьютерных сетей, задачи выбора компромиссных значений в кэшировании, CAP теоремы от Eric Brewer и концепции отложенной согласованности — это все не зря потраченное время.

I/O будут узким местом
Дисковое I/O наверняка будет проблемой в росте вашего приложения, и Raid поверх EBS быстро переполнит сетевое I/O (все пойдет сначала внутрь, а потом наружу, и в итоге будет потребляться двойная пропускная способность). Используйте базу данных оперативной памяти, где это имеет смысл, и кэшируйте все, что только можно! Мы считаем, чтоmemcached достаточно легко использовать, и она очень сильно повлияет на нагрузку базы данных.

Трудно работать с эфемерным хранилищем
Если вы используете локальный диск для хранения данных для лучшего I/O, то вы рискуете потерять данные из-за неисправной работы инстанса. Это может быть ограничено задержкой репликации, временем после последнего снэпшота или временем последнего дампа базы данных, но все это делает восстановление нудным и лакейским.

Мы решаем это в таких проектах как Scalr, где в случае падения слэйв-сервера автоматически становятся мастер-серверами. Однако существует проблема выбора между временем простоя и потерянными данными, который мы делаем, и по умолчанию мы выбираем потерю данных.

Автор статьи: Todd Hoff
Дата: 22 марта 2010
Оригинал статьи

Leave a Reply

Your email address will not be published. Required fields are marked *