?

Log in

No account? Create an account

Previous Entry | Next Entry

Я опубликовал слайды с доклада, который я делал на IT-конференции "Стачка", прошедшей 13-14 апреля 2012 года в Ульяновске. Они, конечно, не смогут рассказать нюансов, но картину в целом, надеюсь, обрисовать способны. Вопросы и предложения можно слать в почту или постить прямо здесь, в комментариях.
Я рассказываю про проблемы с программным обеспечением
Фото взято отсюда у пользователя xeonvs.

Comments

( 13 комментариев — Оставить комментарий )
mclap
16 апр, 2012 10:06 (UTC)
Слайды улыбнули ;-)

Юра, из слайдов не понятно, в чем профит 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 запустить уже нет :)
jay_is_here
16 апр, 2012 10:22 (UTC)
Думаю, что надо сразу сказать, что доклад был только про построение локальной (внутриофисной) инфраструктуры.

> из слайдов не понятно, в чем профит live migration именно на стадии стартапа

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

> а миграция работает при выходе из строя физического сервера?

Например, в XenServer/XCP есть настройки HA, где можно сказать, что такие-то виртуалки всегда должны быть запущены. Тогда, при физическом умирании одного из серверов в пуле, они запустятся на других серверах пула. Но я не знаю, что будет при смерти мастера пула. Про другие гипервизоры сказать не могу..

> В слайдах не хватает пункта - когда нужно завязать с виртуализацией и использовать физические сервера

В случае локальной инфраструктуры - до этого расти и расти :) Но, в принципе, да, ты прав. Если стартап пытается обрабатывать высокие нагрузки, и живет в колокейшне, а не в облачном хостинге, то хорошо бы для нагрузочных тестов иметь реальные сервера, аналогичные используемым в продакшне. Это можно было упомянуть.
mclap
16 апр, 2012 15:43 (UTC)
Железные сервера для тестов при большой нагрузке - без этого никак.

У меня простая схема окружений: production >> test > dev. Где dev - модель production 1:XXX

Точную копию production в качестве test, мы не можем даже разместить. Экономически не оправдано держать такую копию только для "теста".
jay_is_here
16 апр, 2012 10:39 (UTC)
> 1. После нескольких лет использования SAN (8Gb FC, IBM) предложение использовать FreeNAS для "сети хранения данных" вызывает искренюю улыбку.

Тут и я улыбаюсь :) Но про 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. Спасибо за комментарии, появились мысли по дальнейшему улучшению доклада :)
sonny_ko
16 апр, 2012 12:14 (UTC)
Я тоже отвечу как человек, который это эксплуатирует уже два года. Юра как раз про нас и рассказывал.

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

1) Я бы тоже с удовольствием посмеялся, не плати я за оборудование из своего кармана. Разница в цене - минимум в четыре раза. Скорости, достаточной для работы 5-30 человек, можно достичь и в гигабитном эзернете.
2) поэтому я даже не спорю насчёт уровня рейда с Юрой. Только 6й рейд, хоть какая-то защита. Плюс бекап на зеркальное хранилище
3) конечно. А кто с этим спорит? Но тут можно временно переехать на зеркальное хранилище.
4) Подбирать параметры надо. Супергорячие данные можно и на raid1 с двойным резервированием хранить, и плюс ускорители из ssd использовать, современные контроллеры ещё и не такую камасутру умеют.
5) Ну не знаю. Что только мы с ними ни делали - выживают. А при каких случаях ненадёжно?
6) точно. Но не спасает от изъятия техники или от пожара. Миникластер - спасает
7) ну да. и?
mclap
16 апр, 2012 15:23 (UTC)
Комментарии относились к презентации в целом, и для не сильно нагруженных проектов использование виртуализации оправдано - если сервисы на одной желязяке не упираются в I/O, CPU или сеть.

Чего в презентации явно не хватает - это границ применимости виртуализации.

> 5) Ну не знаю. Что только мы с ними ни делали - выживают. А при каких случаях ненадёжно?

Два сервера, одно внешнее хранилище по оптике. С хранилищем работает только один сервер, второй на подхвате. Ловили случаи, когда failover'а нет при сбое активного узла. Решение от крупного известного вендора.

Этот и другие случаи, с которым приходится сталкиваться на моем проекте не типичны для большинства проектов.

> 1) Я бы тоже с удовольствием посмеялся, не плати я за оборудование из своего кармана. Разница в цене - минимум в четыре раза. Скорости, достаточной для работы 5-30 человек, можно достичь и в гигабитном эзернете.

Сколько нулей в сумме $$, расходуемой на ежегодные закупки оборудования изменят могут привести к пересмотру мнения насчёт FreeNAS (вопрос риторический) ? :) Когда очевидно, что выбор "не купить" отсутствует, а смена вендра не даёт существенных скидок (скажем на 50% и более) ?

Где проходит та граница, когда кончается самопал и начинаются проекты с поддержкой от вендора, SLA и прочее ?

> 3) конечно. А кто с этим спорит? Но тут можно временно переехать на зеркальное хранилище.

Клёво, если в проекте это возможно !

С этим не спорил. Оговорился сразу - "Из моего опыта (предоставление доступа к большим массивам данных)".

> 4) Подбирать параметры надо. Супергорячие данные можно и на raid1 с двойным резервированием хранить, и плюс ускорители из ssd использовать, современные контроллеры ещё и не такую камасутру умеют.

Поверь, я про "диски не в рейд" написал не от хорошей жизни. Там где применяют - все уже просчитано.

> 6) точно. Но не спасает от изъятия техники или от пожара. Миникластер - спасает

Риск изъятия в нашей стране очень актуален ;-) Чего стоит история с пейджинговым оператором в Самаре в начале нулевых.
Антон Морозов
24 апр, 2012 14:42 (UTC)
КТО ЗДЕСЬ??
Не попал на твой доклад - на второй день жена заболела :)
Однако, тема актуальная, молодец!
jay_is_here
24 апр, 2012 16:25 (UTC)
Re: КТО ЗДЕСЬ??
Я вам расскажу как-нибудь. Дорогу только надо перейти :)
А ты давай, расти до облачного провайдера, а то обычный хостинг уже не модно :)
Антон Морозов
24 апр, 2012 16:59 (UTC)
Re: КТО ЗДЕСЬ??
Винты надо менять, а у меня пока денег нет лишних. Да и не лишних тоже нет...
Вообще, в случае с OpenVZ всё просто - делаешь между серверами зеркало файлов, каким-нибудь гнустерфсом или подобным, а когда сервер падает - его напарник запускает контейнеры, которые на усопшем были. Для этого домтаточно иметь резерв по памяти - не в два раза, как у меня сейчас, а в три, т.е. не по 16 ГБ ставить на сервер, а по 24. Это не особо дорого.
А вот винты я брал без учёта такой веселухи, так что надо по 1 ТБ хотя бы, а не по 500 МБ, как у меня сейчас. И так инкрементальные бекапы сьедают 70% полезного объёма.
Тогда при умирании сервера даунтайм будет минут 20, потери данных - некритические. В крайнем случае, можно будет кого-нибудь откатить на сутки назад - у меня юзеры несерьёзные, и тому рады.
А щас если сервер помирает - приходится часа два их распаковывать из бекапа и запускать по одному.
А, ну еще сервера-близнецы должны быть в одном VLAN'е, так при запуске виртуалок IP сразу роутятся как должны..
livejournal
17 сент, 2012 06:13 (UTC)
Как на самом деле устроена наша IT-инфраструктура.
Пользователь sonny_ko сослался на вашу запись в «Как на самом деле устроена наша IT-инфраструктура. » в контексте: [...] ;и здесь [...]
(Удалённый комментарий)
jay_is_here
17 сент, 2012 11:36 (UTC)
1. Hyper-V я пока даже не трогал. Там, где сильны позиции Windows Server, оно явно прижилось. Но все пока признают, что Hyper-V все еще в позиции "догоняющих". Периодически в ru_root пробегает ругань, например.

2. Программный RAID плох тем, что ест CPU. Хорош тем, что его легко починить и достать с него данные. Если навернется плата RAID-контроллера, то диски будут лежать до тех пор, пока новую не найдешь. В условиях российской глубинки, это легко может быть неделя-две, а то и месяц. К тому же, многие дешевые RAID-контроллеры часто оказываются fake-RAID, где опять вся логика выполняется на CPU драйверами, а сам контроллер чисто метаданные раскладывает по дискам. На старте при ограниченном бюджете я всегда рекомендую программный RAID.

3. Брендовое железо удобно. Но да, если вдруг с ним что-то случилось, то это надолго и задорого. Поэтому на старте - самосбор. Именно потому, что если что-то сдохло, то это покупается в любом магазине за полчаса.

Но как только компания выходит на уровень, когда нужно обеспечивать скорость и стабильность под нагрузками - имеет смысл переходить на брендовые решения, аппаратные рейды и т.д. Просто держать их с запасом.
(Удалённый комментарий)
( 13 комментариев — Оставить комментарий )