Итак, переходим к самому волнующему: под какой системой виртуализации будет работать наше облако? Простой поиск по интернету выдает такие разнообразные варианты, что прямо теряешься.
На самом деле ответ на этот простой: ставьте ту систему, специалисты по которой наиболее доступны вам. Что бы было у кого и с кого спрашивать.
Но это же не интересно и писать не о чем. Поэтому давайте я опишу личные впечатления о разных системах, которые можно заиспользовать.
Начну с моей любимой: OpenVZ (Коммерческая Virtuozzo). Самая скоростная система, которая по производительности легко уделывает все остальные. Имеет только один, зато толстый минус: позволяет внутри крутить только linux системы.
VMware. Самая старая, дорогая и поддерживаемая система. Есть бесплатные вариант ESXi, но возможностей у него кот наплакал. За деньги можно сделать систему абсолютно любого уровня. Основные минусы: цена и дикая нелюбовь к несертифицированному железу.
Xen. В коммерческом варианте – Citrix. В России я не видел нормальных внедрений, поэтому опыта у меня нет. Зато за рубежом одни из крупнейших провайдеров – Amazon и RackSpace использует именно его.
KVM. На самом деле это простой гипервизор, который есть в любом дистрибутиве линукса. Управляется исключительно из командной строки. Но благодаря поддержке гигантов, оброс различными системами управления и надстройками, которые позволяют конкурировать с системами на базе VMware. RedHat использует именно его.
Hyper-V. Продукт от микрософта и заточенный на работу с микрософтовскими же продуктами. Не так давно научился и linux крутить. Дорогой и пока глючный (ну или мне так везет).
VirtualBox. Бесплатная (для десктопа) виртуализация. Но если вам приходится много работать с Solaris или Oracle, то это единственный выбор.
В общем-то и все. Остальные системы пока в слишком зачаточном состоянии.
По функционалу все системы одинаковы. То есть заморачиваться вопросами «а умеет ли эта система что-то, что не умеет другая» абсолютно нет смысла: все необходимое есть. Разница в том, насколько удобно реализованы те или иные возможности.
К примеру, vmware имеет в комплекте конвертор, который позволяет с минимальными усилиями затащить в себя любую физическую машину, работающую под windows или linux. Она же единственная, кто дружит с OS X. Зато OpenVZ позволяет сделать так, чтобы файловая система (и сама виртуалка) была доступна с хост-машины без каких-либо проблем (и при необходимости наоборот). А KVM доступна на любой линукс-машине и позволяет с минимальными телодвижениями запустить образ от других систем. Ну и если у вас целиком вся инфраструктура на продуктах от микрософта, то с помощью Hyper-V вы мигрируете в облака без особых телодвижений.
В общем, крайне рекомендую перед окончательным выбором протестировать все системы под свои требования. Благо у всех систем есть триальные версии.
Хинт: нет никакой необходимости делать все на одной системе. Никто не мешает использовать несколько. Да, получится более сложная инфраструктура, но возможно более эффективная.
Ндас, как-то не очень маркетоидно получилось, зато про всех понемногу. Давайте лучше вернемся к приятному: планированию облака.
Если помните, то в предыдущей части вы разрисовывали связи и самое большое число связей получилось у сети и дисков. Вот эти две штуки и являются самыми больными частями в любом облаке. Любая неполадка или задержка вызывает вал проблем, который остановить очень сложно.
За что борются инженеры?
Во-первых, за скорость. Диск и сеть должны выдавать максимальные значения, дабы уменьшить простой процессоров на нодах.
Во-вторых, за число операций в секунду. Для дисков это зовется IOPS, для сети pps. Чем больше операций система может провернуть, тем меньше надо систем для обработки того же объема запросов.
Для этих значений принцип простой: чем больше, тем лучше. И поверьте, борьба за эти циферки идет жесточайшая. Их всегда не хватает. Вообще всегда.
Какие основные методы применяют?
Во-первых, разделение машин по функционалу. Скажем, у вас есть 10 веб-серверов. Предположим, что внутри каждого веб-сервера есть сам веб-сервер с каким-то движком (типа php или java) и SQL сервер. Простой вынос всех этих десяти маленьких SQL серверов на один (хорошо, на два, если нужна отказоустойчивость), но которому отдали их ресурсы, уже приведет к увеличению производительности.
Во-вторых, разделение потоков данных. Это тема в большинстве случаев сродни шаманству. Людей, которые понимают, где в обычных с виду систем могут возникать бутылочные горлышки и как их удалять, очень ценят.
Скажем же веб-сервер. Скажем, ему банально стало не хватать производительности. Поднять второй по каким-то причинам нельзя. Что делают в «лоб»? Обычно наращивают производительность. Скажем ставят SSD вместо обычных дисков. Да, производительность возрастет, но не сильно. Специалист «по горлышкам» придет и увидит, что у веб-сервера есть один поток на чтение, когда он отдает запрошенное, один поток на запись, когда он записывает в лог и еще один поток на запись, когда операционная система обновляет время последнего доступа к файлу. В результате достаточно отрубить время доступа (нафиг он на веб-сервере?) и поднять где-нибудь неподалеку сервер для сбора логов, как дисковой подсистеме отвечающей за веб-сервера резко полегчает: она будет работать только на чтение (и никто не мешает ей поставить RO, что бы еще больше облегчить жизнь). А у сервера логов только на запись. Все счастливы и довольны.
Есть и еще одно «шаманство». Обзывается разделением нагрузки по характеру. Скажем, у нас есть бухгалтерия и почта. Бухгалтерский сервер использует паттерн работы с диском «тут посмотрели, тут записали, тут посмотрели, тут записали» (упрощенно конечно). А почта «записали, посмотрели, посмотрели, посмотрели, записали». Причем временные интервалы и расстояния по диску между «посмотрели» и «записали» у обоих систем разные. В результате кэш, который обязан ускорять работу с диском, банально «загрязняется» и работает далеко не так эффективно, как мог бы.
Да, примеры немного наиграны, но и реальность просто отличается большим числом участвующих «переменных».
Ладно, хватит пугать, надо немного рассказать о типичных методах ускорения сети и дисков и встреченных мной (и совершенных тоже) ошибках.
Объединение линков. Как я писал выше, скорости никогда не хватает. Все сетевые штуки умеют объединять несколько сетевых линков в один. Скажем, у вас в сервере есть 4 порта, каждый на 1Гбит. И в коммутаторе тоже образовалось свободное место. Вы берете 4 патч-корда и соединяете их один-к-одному, включаете бондинг (объединяете их в один транк и так далее) и надеетесь, что в результате получите линк на 4Гбит. А в результате получаете тот же гигабит или чуть больше. Любой продвинутый сетевик уже понял, в чем засада. Для остальных: у бондинга много режимов и вариантов. И только некоторые предусматривают возможность распределение нагрузки по всем линкам.
Звезда – наше все. Это любимая и продвигаемая большинством модель построения сети. Если коротко, то все сетевые устройства подключаются к некой системе, которая уже и занимается передачей пакетов от одного устройства к другому. Просто, понятно и … дорого. Штуки, которые способны переваривать десятки и сотни гигабит (Откуда такие цифры? К примеру, одна виртуалка с бухгалтерией легко генерирует поток в гигабит к диску. Это всего-то 100 мегабайт в секунду. Обычный винт легко выдает) и при этом не становиться единой точкой отказа, стоят дорого. Для обычной сети эта модель практически идеальна. Но у облаков все немного по-другому. Скажем, есть очень большой поток данных между серверами хранения. Не к нодам, а тупо между собой. Для репликации, отказоустойчивости и все прочее. Более того, весь поток сосредоточен между серверами одной группы. Так зачем его гонять через коммутатор, когда гораздо выгодней зацепить сервера между собой прямыми линками? Просто из-за такого изменения топологии задержка в линке падает больше чем в 2 раза! И ведь точно такой же поток данных есть и между нодами …
Не все рэйды одинаково полезны. Скажем, нам нужно создать отказоустойчивый сервер хранения. Надо немного, буквально 20 терабайт. Что делает обычный, не «облачный» админ? Берет два сервера, пихает в каждый по шесть дисков на 4 терабайта, запихивает их в raid5 на отдельном контроллере, объединяет сервера и рапортует о готовности. В результате получается тормозной сторадж, который с трудом способен переварить 400-500 мегабайт данных в секунду. Что делает облачный админ? Берет десять дисков по паре терабайт, делает raid0 средствами операционной системы и затем объединяет сервера. Получившаяся шарманка легко берет планку гигабайт в секунду и не дохнет от на порядок больших IOPSов. Да и еще дешевле оказывается. Почему так получилось? Во-первых, облачный админ исключил лишний уровень отказоустойчивости. Зачем его дублировать на уровне дисков, когда он уже есть на уровне серверов? Во-вторых, raid0 сам по себе работает гораздо быстрее raid5, а тут вдобавок данные обрабатывают 10 дисков против 5 (и не надо ждать, пока raid5 завершит запись на всех дисках). И наконец, он освободил ресурсы процессора от расчета всяких контрольных сумм (если кто-то думает, что отдельные raid контроллеры работают быстрее обычного процессора, то он очень сильно заблуждается). Результат: выигрыш в скорости, выигрыш в IOPSах, выигрыш в деньгах! Сплошной профит!
SSD супротив памяти проигрывает всегда! Последнее время пошла мода ставить SSD для кеширования обычных HDD. Для десктопов это реально увеличивает скорость общения с диском. А вот с облаками эта штука практически не дает прироста. Просто из-за того, что слишком хорошо распределена нагрузка и редко когда в SSD попадает то, что можно закешировать. А ставить их пачками – дорого. Но почему-то редко кто додумывается поставить на сервер хранения не жалкие 16-32 гига памяти, а 256 или 512 и оттюнить операционку на максимальное использование кэша. Поверьте, эффект будет заметен невооружённым взглядом.
Но и это не все, над чем придется поломать голову. При переводе систем в облака крайне рекомендую заранее озаботиться в их установке в варианте, который позволяет масштабироваться с минимальными усилиями или исключить ненужное дублирование. Скажем, для систем на базе jboss можно почти расслабиться: он сам умеет находить аналогичные сервера и парралелить работу. Сервера с MySQL достаточно сразу поднимать в не в конфигурации standalone, а master: потом подцепить другой master или slave будет гораздо проще. Резервное копирование осуществлять не с помощью агентов изнутри каждой виртуалки, а централизовано, на сервере хранения.
Хинт: определить, что лишнее, довольно просто. Просто берете и мысленно ставите рядом еще одну точно такую же систему. Общие данные и там и там? Выносим на отдельную виртуалку/общий каталог на сторадже. Один и тот же сервис делает одну и ту же работу с одним набором данных? В отдельную виртуалку! Какой-то внешний сервис приходит регулярно за каким-то данными? Меняем схему, что бы не он приходил, а мы ему отправляли. И так далее и тому подобное.
В результате у вас должно получиться примерно в 3-4 раза больше «облачных» серверов, чем было «физических» сервисов. Но все сервера будут выполнять одну функцию, их будет легко собрать в группы по характеристикам и все они будут довольно легко масштабироваться.
Только заклинаю вас: сразу все определите правила для поименования, нумерации сети и документирования. Нет ничего хуже, чем обозревать сеть с server1, server2, test-server, lama, vanya (брать имена городов, животных, клички ничем не лучше). Поверьте, даже для небольшой компании со временем легко набирается сотня-другая виртуальных серверов. В имени сервера должно присутствовать как минимум указание на его функциональную сущность (например stor, node, app, web), его уникальный номер (хорошо если привязанный к его адресу в сети) и если необходимо, какой-либо другой признак (dev, ivan, test). А за отход от правил тут же и немедленно бить чем угодно. Но еще лучше помогает тупо удаление сервера: второй раз никто такую ошибку обычно не допускает.
И тогда любой при взгляде на stor25fast сможет сказать, что это сервер хранения для требовательных к ресурсам задач с адресом 10.0.0.25, a web40-test-ivan – тестовая машинка с веб-сервером, поднятая Иваном и имеющая адрес 172.16.0.40. Думаю, смысл понятен.
Думаю, я достаточно загрузил вас. Пора немного прерваться.
И да, я опять спер картинку