Виртуализация и кластеры

[X-RaY™]

Здравствуйте, вопрос дилетантский, но всё же. Планируем перенести все софтовое добро в виртуальные машины, совсем всё, то есть от рабочих мест сотрудников(тоникие клиенты) до днс, хостинга и так далее. Встал вопрос как быть с биллингом(abills) переносить его просто на 2 отдельных физических сервера(кластер) или переносить тоже в общий котел, на виртуалки. Что будет лучше и производительней, кластер из 5 серверов и в них крутится всё или 3 сервера под приложения,а биллинг отдельно на 2х машинах.

Сервера ксеоны новые и ссд винты для систем+просто винты под данные, так же рассматриваем вариант выноса все на отдельное схд. Буду благодарен за советы и рекомендации. Спасибо.

[vlad11]

Идея хорошая, но тяжко реализуемая и сопровождаемая :(

[X-RaY™]

Но 10+ тазиков + десятки рабочих мест, тоже не простое занятие , к сожалению.

[vlad11]

Клиентские тазики значительно проще поддерживать.

PXE сервер, гигабитный свитч, загрузка по сети и все работают.

 

Я бы взялся за проект, но раньше лета не смогу выкроить время на тестирование проекта отказоустойчивого приватного облака (кластера).

Edited February 24, 2012 by vlad11

[NiTr0]

А смысл abills запихивать в VM, если он прекрасно кластеризуется на уровне сервисов? :) MySQL active-active кластер, ну и httpd/radius/dhcp + ip в виде мигрирующего ресурса...

И да, все с интенсивным дисковым/сетевым i/o лучше не виртуализировать. И то, что может быть кластеризировано на уровне сервисов и не требует выноса на VM из соображений безопасности, лучше тоже не виртуализировать.

[SergeiK]

Здравствуйте, вопрос дилетантский, но всё же. Планируем перенести все софтовое добро в виртуальные машины, совсем всё, то есть от рабочих мест сотрудников(тоникие клиенты) до днс, хостинга и так далее. Встал вопрос как быть с биллингом(abills) переносить его просто на 2 отдельных физических сервера(кластер) или переносить тоже в общий котел, на виртуалки. Что будет лучше и производительней, кластер из 5 серверов и в них крутится всё или 3 сервера под приложения,а биллинг отдельно на 2х машинах.

Сервера ксеоны новые и ссд винты для систем+просто винты под данные, так же рассматриваем вариант выноса все на отдельное схд. Буду благодарен за советы и рекомендации. Спасибо.

Статистику с систем по загрузке поснимали? Оценили? Исходя из результатов и действовать.

Платформу виртуализации выбрали? Коммерческие или бесплатные решения?

Умеют ли ограничивать и гарантировать ресурсы для систем?

 

Система хранения - это хорошо, правильно, но для неё надо считать надежность, ибо риск потерять все велик.

 

Рабочие станции-то зачем? Тонкий клиент большей частью себя не окупает. Хотя, я, вполне возможно, что-то не знаю...

 

В целом, в теории сейчас тенденция все в виртуальность, не взирая на потери производительности.

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

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

И чтоб памяти было дохера.

[SergeiK]

А смысл abills запихивать в VM, если он прекрасно кластеризуется на уровне сервисов? :) MySQL active-active кластер, ну и httpd/radius/dhcp + ip в виде мигрирующего ресурса...

И да, все с интенсивным дисковым/сетевым i/o лучше не виртуализировать. И то, что может быть кластеризировано на уровне сервисов и не требует выноса на VM из соображений безопасности, лучше тоже не виртуализировать.

 

Смысл VM не кластеризация, смысл - в сокращении объема железа и рациональном использовании ресурсов.

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

 

Проблем с дисковыми и сетевыми операциями нет, если вы не гигабитный роутер, конечно, виртуализируете :).

Но для оценки надо узнать потребности систем, прежде всего.

 

Нет проблем совмещать кластеризацию и виртуализацию, эти вещи - суть разные явления.

Иногда можно одним заменить другое, не не всегда можно и тем более не всегда нужно.

Да, так же и система хранения высокой надежности не избавит от необходимости делать резервные копии.

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

Поэтому что второй независимый рабочий сервер, как и резервную копию все равно надо иметь :).

[s.lobanov]

А смысл abills запихивать в VM, если он прекрасно кластеризуется на уровне сервисов? :) MySQL active-active кластер, ну и httpd/radius/dhcp + ip в виде мигрирующего ресурса...

И да, все с интенсивным дисковым/сетевым i/o лучше не виртуализировать. И то, что может быть кластеризировано на уровне сервисов и не требует выноса на VM из соображений безопасности, лучше тоже не виртуализировать.

 

Смысл VM не кластеризация, смысл - в сокращении объема железа и рациональном использовании ресурсов.

Дополнительная надежность - приятная опция, но большей частью платная.

 

Можно поспорить. Мне известен случай, когда делали решение на vspere исключительно из-за прозрачной(по отношению к ОС и приложениям) кластеризации, т.к. иногда затраты на имплементацию программной кластеризации слишком велики, проще сделать vmware FT

[SergeiK]

Ну-у, это, конечно, возможно, но все же не mainstream.

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

Большинство современных сетевых приложений так или иначе можно сделать достаточно надежными без этаких фокусов.

И, как написал, одно другого не исключает, а дополняет.

[Ilya Evseev]

Встал вопрос как быть с биллингом(abills) переносить его просто на 2 отдельных физических сервера(кластер) или переносить тоже в общий котел, на виртуалки.

Что будет лучше и производительней, кластер из 5 серверов и в них крутится всё или 3 сервера под приложения,а биллинг отдельно на 2х машинах.

1) все сервисы должны работать не на физических серверах (HN), а в виртуальных контейнерах,

2) исключение - если сервису нужен доступ к оборудованию, иногда проще запустить этот сервис прямо на HN, чем прокидывать доступ в контейнер.

3) в одном контейнере должен работать ровно один сервис,

4) исключение - несколько сервисов уместно держать в одном контейнере до тех пор, пока он не потребляет много ресурсов,

если у них одинаковый громоздкий runtime environment и одинаковый круг пользователей.

5) кластер должен включать в себя не меньше двух HN с возможностью live migration.

6) для запуска нового контейнера выбирается наименее загруженная HN.

7) делать раздельные кластеры для разных групп приложений имеет смысл imho только в том случае,

если им нужны разные сетевые топологии (для производительности, безопасности и т.д.), несовместимые в рамках одного кластера.

 

В общем, делайте один кластер из пары нод, все сервисы распихивайте по контейнерам и не парьтесь.

[NiTr0]

Смысл VM не кластеризация, смысл - в сокращении объема железа и рациональном использовании ресурсов.

Не спорю. Но это совсем не значит, что виртуализировать нужно всё и вся.

 

Дополнительная надежность - приятная опция, но большей частью платная.

heartbeat + libvirt в помощь...

 

Проблем с дисковыми и сетевыми операциями нет, если вы не гигабитный роутер, конечно, виртуализируете :).

Проблем-то нет. Но накой виртуализировать задачи, которые не требуют изоляции по соображениям безопасности, у которых имеется интенсивный ввод-вывод (в данном случае - мускул по мере разрастания БД ой как шуршать дисками будет) и соответственно солидный оверхид на его виртуализацию, которые должны иметь высокий приоритет и утилизировать в случае необходимости все свободные ресурсы, а не выделенные ядра, и тем более которые должны подняться в случае падения одной из нод в максимально короткие сроки (в идеале - менее минуты) на другой железке? А с виртуалками это нереализуемо - как минимум, если падает виртуалка во время записи в БД, получаем порушенные таблицы, возможно - порушенную ФС, и восстановление их будет занимать не 1-2 минуты...

 

P.S. При утилизации проца различными виртуалками эдак % на 50-70 резко растет оверхид на переключение контекста задач, и производительность может просесть эдак раза в 2...

Edited February 24, 2012 by NiTr0

[SergeiK]

Смысл VM не кластеризация, смысл - в сокращении объема железа и рациональном использовании ресурсов.

Не спорю. Но это совсем не значит, что виртуализировать нужно всё и вся.

Всегда надо пользоваться головой, это как бы "by default".

 

Дополнительная надежность - приятная опция, но большей частью платная.

heartbeat + libvirt в помощь...

Повторю, это разные опции. Одно другому не мешает, но разные и по разному работают.

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

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

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

 

Но никто не мешает поднять два сервера виртуализации и на виртуальных машинах делать тот же кластер.

Для SMB (Small Bussiness) виртуализация доступна бесплатно :).

Проблем с дисковыми и сетевыми операциями нет, если вы не гигабитный роутер, конечно, виртуализируете :).

Проблем-то нет. Но накой виртуализировать задачи, которые не требуют изоляции по соображениям безопасности, у которых имеется интенсивный ввод-вывод (в данном случае - мускул по мере разрастания БД ой как шуршать дисками будет) и соответственно солидный оверхид на его виртуализацию, которые должны иметь высокий приоритет и утилизировать в случае необходимости все свободные ресурсы, а не выделенные ядра, и тем более которые должны подняться в случае падения одной из нод в максимально короткие сроки (в идеале - менее минуты) на другой железке? А с виртуалками это нереализуемо - как минимум, если падает виртуалка во время записи в БД, получаем порушенные таблицы, возможно - порушенную ФС, и восстановление их будет занимать не 1-2 минуты...

 

P.S. При утилизации проца различными виртуалками эдак % на 50-70 резко растет оверхид на переключение контекста задач, и производительность может просесть эдак раза в 2...

Мы говорим о серьъезном решении с системой хранения? Там нет проблем с "шуршать дисками". Но даже в случае легкой виртуализации можно выделить отдельные диски под БД. Вопрос дизайна.

 

"Все в виртуализацию!" подразумевает наличие нескольких серьезных серверов с современными процессорами, которые на уровня ядер поддерживают виртуализаию, и вопрос контекста значительно снимает, с большим количеством памяти (реально большим, поддерживается по почти терабайта), и внешней системой хранения. И виртуальных машин на таких системах может быть от 20 до 40 на сервер, в зависимости от....

По стоимости развертывания это будет не сильно дешевле, чем отдельно стоящие сервера, если не дороже.

Но по полученной гибкости и надежности намного лучше. Ну и плотность размещения и потребление энергии намного лучше.

 

Да, для серьезной виртуализации еще хорошо ложится блейдовая архитектура и плотность логических серверов на стойку можно получить впечатляющую!

Правда и теплоотвод от такой стойки надо будет делать Очень приличный.

Но все равно в разы меньше в пересчете на логический сервер, чем в традиционной архитектуре.

[NiTr0]

Мы говорим о серьъезном решении с системой хранения? Там нет проблем с "шуршать дисками".

Зато есть проблема с обменом по сети. Который тоже виртуализируется, и оверхид существенный.

 

"Все в виртуализацию!" подразумевает наличие нескольких серьезных серверов с современными процессорами, которые на уровня ядер поддерживают виртуализаию, и вопрос контекста значительно снимает

Не снимает. Пригрузите ваш мегасервер так, чтобы загрузка по ядрам была % по 80 - и удивитесь, насколько реально падает быстродействие в задачах, крутящихся в виртуалках. Потому как аппаратное переключение контекста задач тоже занимает не одну сотню тактов, а возможно - и не одну тысячу.

[s.lobanov]

NiTr0

Сравнивать решения кластерной виртуализации(или как сейчас модно говорить, облака) с физическими серверами это как сранивать >=L3 Cisco оборудование с PC-based решения, чистая себестоимость может получиться меньше у 2ого варианта при одинаковой производительности, но кол-во геморроя несоизмеримо.

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

[NiTr0]

Кому как. Я, к примеру, не вижу смысла городить FC или 10GE с отдельным стораджем и минимум 3 ноды (для кворума - ибо в противном случае split brain будет веселым в случае чего) там, где оно не сильно востребовано. Облака - оно, конечно, хорошо, только вот не везде и не всегда оптимально.

Да и странно слышать о "разбирательствах с фан/темп контроллерами и рэйд-контроллерами" - собссно это девайсы из серии "настроил за минуту и забыл". Ибо ни контроллеры эти с ноды на ноду не мигрируют (т.к. ползать не обучены, а то и вообще впаяны), ни софт, с ними напрямую общающийся...

[adnull]

Не знаю, ребята. Виртуализация вещь хорошая, но там тоже своих костылей хватает. На qemu надо наворачивать virtio драйверы, чтобы все хорошо работало. С Виндой проблемы по производительности. Сводить кучу сервисов в одну точку отказа.. И потом - диски, шина у сервера общие, никакой виртуализацией не ограничишь. Словит "клиент" вируса и положит весь гипервизор. Теоретически, конечно. Я бы биллинг точно в ВМ не запихивал.

Ну и обслуживать все это добро надо. Тоже человек опытный требуется.

[Alex/AT]

В качестве стартового решения я бы советовал брать VMWare ESXi. Если понравится - пересаживаться на коммерческую версию VSphere, с VMotion и прочими необходимыми плюшками. Гипервизор очень хорош, и позволяет реализовать множество способов защиты от "клиент словит вирус", вплоть до ограничений по IOPS. Единственный нюанс - очень прихотлив к железу, обязательно смотрите HCL прежде чем брать сервер под это дело. Аппаратный RAID (а если планируете миграцию при отказах, то - сразу либо NAS, либо многопортовый DAS) - обязателен.

 

P.S/offtop Хотя, если честно, помимо продакшна ныне уже юзаю это "прихотливое создание" даже дома, очень удобно для массы сборочных/тестовых площадок, и собрать под это дело даже commodity платформу оказалось вовсе не так сложно, как казалось на первый взгляд.

Edited February 25, 2012 by Alex/AT

[adnull]

VMware жутко тормозит (юзаем v-sphere, работает все на блэйде). Причем - все оценочные показатели машины в норме (диск, LA, память). И не только мы это заметили. Полная виртуализация слишком сильный оверхед делает по вводу-выводу. Надо смотреть в сторону паравируализации, хотя бы в плане драйверов.

[Alex/AT]

VMware жутко тормозит (юзаем v-sphere, работает все на блэйде). Причем - все оценочные показатели машины в норме (диск, LA, память). И не только мы это заметили. Полная виртуализация слишком сильный оверхед делает по вводу-выводу. Надо смотреть в сторону паравируализации, хотя бы в плане драйверов.

А вы паравиртуализованные драйверы VMWare в гостевых осях используете? Железо всё по HCL? У меня везде используется pvscsi + vmxnet3 + memory ballooning, особых проблем с производительностью не отмечал даже при топовых нагрузках (~99% CPU core, ~90% memory, ~70% disk IOPS). Даже на commodity, на котором далеко не всё по HCL. Естественно, производительность по CPU ниже собственно сырой железной площадки где-то на 10-15%, но для виртуализации сие очень хорошо.

 

Да, на практике ESXi память жрет безбожно - делайте запас где-то в 50% от расчетного "сырого" потребления. Можно учесть возможный балунинг и прочее, но лучше перестраховаться.

Edited February 25, 2012 by Alex/AT

[adnull]

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

Дальше - клиент управления v-sphere весит почти гиг в дистрибутиве. Там еще ряд неприятных недостатков. В итоге - перелезли на KVM там где нужно виртуализовать винду и FreeBSD и OPENVZ там где linux.

Edited February 25, 2012 by adnull

[Alex/AT]

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

Конечно. Виртуализация - совершенно отдельная область, живущая своей жизнью. Там свои нюансы. "Безгрешной" виртуализации не бывает вообще.

 

FreeBSD и OPENVZ там где linux

OpenVZ (а тем паче - FreeBSD Jail) - "виртуализация" только на бумаге. Это контейнеры, изолированные окружения, а не виртуализация системы в прямом понимании. Любой kernel panic или OOM свалит всю площадку, вместе со всеми контейнерами. Годно для mass hosting, весьма, где полной виртуализации не требуется, а требуется только изолировать клиентов и однотипные среды друг от друга.

Edited February 25, 2012 by Alex/AT

[adnull]

openvz вообще не виртуализация :)

У нас задачи другие стоят. Скорее дать гарантированные ресурсы, нежели запускать стопицот разного барахла на одной железке.

Но vmware оставила в основном негативные впечатления. Субъективно, ессесно.

[Alex/AT]

Да ну почему же. Виртуализация, только на уровне окружения, не на уровне площадки.

 

Если речь о гарантированных ресурсах для однотипной среды - OpenVZ как раз то, что доктор прописал. VMWare нужен там, где вертятся разнотипные приложения, и в разных средах. Ну и Live-миграция там очень удобно сделана при использовании NAS/DAS - пара щелчков мышью (если аварийная ситуация, то автоматически), несколько секунд, и виртуальный сервер уже крутится на соседней площадке, даже сетевые сеансы не теряются. На OpenVZ такое руками (с использованием dump/restore встроенных) реализовывал - можно, но грабельно, в Virtuozzo вроде из коробки, но в данном случае коммерческого решения не пробовал, увы. На KVM лучше даже не пробовать (хотя... может что-то уже изменилось, давно не трогал) :)

Edited February 25, 2012 by Alex/AT

[NiTr0]

На KVM лучше даже не пробовать

Вроде как уже давно live миграция есть, причем - даже с синхронизацией/переносом образа винта при отсутствии NAS/SAN/прочих DRBD. И вроде даже работает...

Хотя все равно миграция сервиса (читать: перенос IP и поднятие демона) куда приятнее, чем миграция виртуалки, и куда безопаснее для данных при внезапном отказе ИМХО.

[adnull]

KVM щас сильно развивается. Xen как Citrix купил, так походу OSS версию и подзабросили..

Ну в итоге выяснилось, что админу еще и в тонкости v-sphere вникать. Еще и лицензию на каждую машину 20$ в месяц купи. Линукс на нем крутить безыдейно, коль есть openvz. Ну а винду уж на KVM крутим, ничего никому не платим и админу много нового изучать не надо :)