Я опубликовал слайды с доклада, который я делал на IT-конференции "Стачка", прошедшей 13-14 апреля 2012 года в Ульяновске. Они, конечно, не смогут рассказать нюансов, но картину в целом, надеюсь, обрисовать способны. Вопросы и предложения можно слать в почту или постить прямо здесь, в комментариях.
Фото взято отсюда у пользователя 
xeonvs.
xeonvs.
Page Summary
Designed by chasethestars
chasethestars
Comments
Юра, из слайдов не понятно, в чем профит live migration именно на стадии стартапа. Для средних и крупных контор цели использования виртуализации понять могу. Live migration, полагаю, что тоже - приложение в одном экземпляре, нагрузка небольшая, должно работать 24x7 (а миграция работает при выходе из строя физического сервера ?)
В слайдах не хватает пункта - когда нужно завязать с виртуализацией и использовать физические сервера.
Из моего опыта (предоставление доступа к большим массивам данных):
1. После нескольких лет использования SAN (8Gb FC, IBM) предложение использовать FreeNAS для "сети хранения данных" вызывает искренюю улыбку.
2. Споры по RAID X vs Y, также вызывают улыбку, когда в течении 12 часов последовательно выходят из строя 3 SAS диска в RAID6 при нагрузке до 15M SQL запросов в минуту.
3. Ребилд рейда на XX TB на живую - это ж@па на сутки-двое. Скорость ребилда регулируется, но I/O все равно проседает.
4. Использование диски без рейда vs диски в рейде на внеших хранилищах - в ряде случаев существенный penalty по скорости при использовани рейда
5. Failover cluster (несколько серверов работают с одним внешним хранилищем, активен только один) - не надежно.
6. SAN вообще - дорого (лицензируется по числу портов), и не всегда хорошо поддеживается (Windows - OK, Linux - OK, FreeBSD - FAIL). Если есть возможность, то DAS (direct attached storage) дешевле.
7. На серверах иногда ломается локальный рейд - в итоге ssh туда можно, а /bin/ls запустить уже нет :)
> из слайдов не понятно, в чем профит live migration именно на стадии стартапа
Если у тебя один сервер виртуализации и одна СХД, то тут о миграции говорить смысла нету. Если стартап вырос до использования двух серверов виртуализации в пуле, значит, либо у них все не влазит в один сервер, либо им нужна высокая доступность инфраструктуры.
> а миграция работает при выходе из строя физического сервера?
Например, в XenServer/XCP есть настройки HA, где можно сказать, что такие-то виртуалки всегда должны быть запущены. Тогда, при физическом умирании одного из серверов в пуле, они запустятся на других серверах пула. Но я не знаю, что будет при смерти мастера пула. Про другие гипервизоры сказать не могу..
> В слайдах не хватает пункта - когда нужно завязать с виртуализацией и использовать физические сервера
В случае локальной инфраструктуры - до этого расти и расти :) Но, в принципе, да, ты прав. Если стартап пытается обрабатывать высокие нагрузки, и живет в колокейшне, а не в облачном хостинге, то хорошо бы для нагрузочных тестов иметь реальные сервера, аналогичные используемым в продакшне. Это можно было упомянуть.
У меня простая схема окружений: production >> test > dev. Где dev - модель production 1:XXX
Точную копию production в качестве test, мы не можем даже разместить. Экономически не оправдано держать такую копию только для "теста".
Тут и я улыбаюсь :) Но про FreeNAS могу сказать следующее. Во-первых, iXsystems делает на базе FreeNAS свои NASы (TrueNAS), в которых есть, например, та же репликация между нодами (если верить списку фич). Во-вторых, там ZFS, что позволяет использовать дедупликацию. А это, в свою очередь, сильно удобно, когда у тебя много практически одинаковых виртуалок. Обратная сторона - значительно больше требования к памяти и просадка скорости записи. Впрочем, в NexentaStor это тоже есть.
> 2. Споры по RAID X vs Y, также вызывают улыбку, когда в течении 12 часов последовательно выходят из строя 3 SAS диска в RAID6 при нагрузке до 15M SQL запросов в минуту.
> 3. Ребилд рейда на XX TB на живую - это ж@па на сутки-двое. Скорость ребилда регулируется, но I/O все равно проседает.
> 4. Использование диски без рейда vs диски в рейде на внеших хранилищах - в ряде случаев существенный penalty по скорости при использовани рейда
Все это верно, при использовании в продакшне. Я говорил про локальные инфраструктуры, где требования по нагрузке все-таки сильно ниже. А вот по сохранности данных - такие же.
> 5. Failover cluster (несколько серверов работают с одним внешним хранилищем, активен только один) - не надежно.
Если ты про схему с двумя реплицируемыми хранилищами - достаточно надежно для локальной инфраструктуры. Например, решает проблему с убитым I/O при перестройке RAID. Ну и удваивает вероятность сохранить данные :)
> 6. SAN вообще - дорого (лицензируется по числу портов), и не всегда хорошо поддеживается (Windows - OK, Linux - OK, FreeBSD - FAIL). Если есть возможность, то DAS (direct attached storage) дешевле.
В том-то и дело, что DAS к серверам виртуализации не прицепишь так, чтобы live migration работала. Придется копировать образы (или хотя бы дельту между ними) по сети на другой сервер перед запуском VM на нем. Софтверный SAN вполне себе решение, потому что лицензируется по объему, как правило. Про аппаратные решения я даже и не говорил.
Есть еще вариант - кластерные ФС типа POHMELFS, где одни и те же данные хранятся сразу на нескольких хостах (3, как правило). Но пока я про них ничего не могу сказать - не довелось еще поработать. И там тоже есть свои грабли. В частности, в том, как ее прицепить к "коробочному" гипервизору.
> 7. На серверах иногда ломается локальный рейд - в итоге ssh туда можно, а /bin/ls запустить уже нет :)
Поэтому, лучше использовать "коробочные" гипервизоры в пуле. Вырубил сервер, засетапил его с нуля и воткнул в пул обратно. На все уйдет примерно полчаса. А еще лучше, если он будет грузиться по PXE с чего-то другого достаточно отказоустойчивого, но это опять же избыточно для локальной инфраструктуры.
P.S. Спасибо за комментарии, появились мысли по дальнейшему улучшению доклада :)
Профита в live migration - только беспрерывность работы. Для нашей бухгалтерской конторы это очень важно. При выходе из строя физического сервера оно не работает, конечно. Там есть другие инструменты, мы до них не добрались пока ввиду ненадобности такой уж крутой стабильности
1) Я бы тоже с удовольствием посмеялся, не плати я за оборудование из своего кармана. Разница в цене - минимум в четыре раза. Скорости, достаточной для работы 5-30 человек, можно достичь и в гигабитном эзернете.
2) поэтому я даже не спорю насчёт уровня рейда с Юрой. Только 6й рейд, хоть какая-то защита. Плюс бекап на зеркальное хранилище
3) конечно. А кто с этим спорит? Но тут можно временно переехать на зеркальное хранилище.
4) Подбирать параметры надо. Супергорячие данные можно и на raid1 с двойным резервированием хранить, и плюс ускорители из ssd использовать, современные контроллеры ещё и не такую камасутру умеют.
5) Ну не знаю. Что только мы с ними ни делали - выживают. А при каких случаях ненадёжно?
6) точно. Но не спасает от изъятия техники или от пожара. Миникластер - спасает
7) ну да. и?
Чего в презентации явно не хватает - это границ применимости виртуализации.
> 5) Ну не знаю. Что только мы с ними ни делали - выживают. А при каких случаях ненадёжно?
Два сервера, одно внешнее хранилище по оптике. С хранилищем работает только один сервер, второй на подхвате. Ловили случаи, когда failover'а нет при сбое активного узла. Решение от крупного известного вендора.
Этот и другие случаи, с которым приходится сталкиваться на моем проекте не типичны для большинства проектов.
> 1) Я бы тоже с удовольствием посмеялся, не плати я за оборудование из своего кармана. Разница в цене - минимум в четыре раза. Скорости, достаточной для работы 5-30 человек, можно достичь и в гигабитном эзернете.
Сколько нулей в сумме $$, расходуемой на ежегодные закупки оборудования изменят могут привести к пересмотру мнения насчёт FreeNAS (вопрос риторический) ? :) Когда очевидно, что выбор "не купить" отсутствует, а смена вендра не даёт существенных скидок (скажем на 50% и более) ?
Где проходит та граница, когда кончается самопал и начинаются проекты с поддержкой от вендора, SLA и прочее ?
> 3) конечно. А кто с этим спорит? Но тут можно временно переехать на зеркальное хранилище.
Клёво, если в проекте это возможно !
С этим не спорил. Оговорился сразу - "Из моего опыта (предоставление доступа к большим массивам данных)".
> 4) Подбирать параметры надо. Супергорячие данные можно и на raid1 с двойным резервированием хранить, и плюс ускорители из ssd использовать, современные контроллеры ещё и не такую камасутру умеют.
Поверь, я про "диски не в рейд" написал не от хорошей жизни. Там где применяют - все уже просчитано.
> 6) точно. Но не спасает от изъятия техники или от пожара. Миникластер - спасает
Риск изъятия в нашей стране очень актуален ;-) Чего стоит история с пейджинговым оператором в Самаре в начале нулевых.
Однако, тема актуальная, молодец!
А ты давай, расти до облачного провайдера, а то обычный хостинг уже не модно :)
Вообще, в случае с OpenVZ всё просто - делаешь между серверами зеркало файлов, каким-нибудь гнустерфсом или подобным, а когда сервер падает - его напарник запускает контейнеры, которые на усопшем были. Для этого домтаточно иметь резерв по памяти - не в два раза, как у меня сейчас, а в три, т.е. не по 16 ГБ ставить на сервер, а по 24. Это не особо дорого.
А вот винты я брал без учёта такой веселухи, так что надо по 1 ТБ хотя бы, а не по 500 МБ, как у меня сейчас. И так инкрементальные бекапы сьедают 70% полезного объёма.
Тогда при умирании сервера даунтайм будет минут 20, потери данных - некритические. В крайнем случае, можно будет кого-нибудь откатить на сутки назад - у меня юзеры несерьёзные, и тому рады.
А щас если сервер помирает - приходится часа два их распаковывать из бекапа и запускать по одному.
А, ну еще сервера-близнецы должны быть в одном VLAN'е, так при запуске виртуалок IP сразу роутятся как должны..
2. Программный RAID плох тем, что ест CPU. Хорош тем, что его легко починить и достать с него данные. Если навернется плата RAID-контроллера, то диски будут лежать до тех пор, пока новую не найдешь. В условиях российской глубинки, это легко может быть неделя-две, а то и месяц. К тому же, многие дешевые RAID-контроллеры часто оказываются fake-RAID, где опять вся логика выполняется на CPU драйверами, а сам контроллер чисто метаданные раскладывает по дискам. На старте при ограниченном бюджете я всегда рекомендую программный RAID.
3. Брендовое железо удобно. Но да, если вдруг с ним что-то случилось, то это надолго и задорого. Поэтому на старте - самосбор. Именно потому, что если что-то сдохло, то это покупается в любом магазине за полчаса.
Но как только компания выходит на уровень, когда нужно обеспечивать скорость и стабильность под нагрузками - имеет смысл переходить на брендовые решения, аппаратные рейды и т.д. Просто держать их с запасом.