Disclaimer: Все утверждения в данной статье основаны на опыте инженеров компании Тринити.

Данная статья создана при активном содействии участников форумов
http://www.3nity.ru
http://forum.ixbt.com/?id=66

Смысл данной статьи - помочь начинающим серверостроителям, системным администраторам и всем, кто принимает решение о составе/комплектации приобретаемого сервера, избежать ряда типичных ошибок. Статья не о том, как надо делать, а о том, как делать НЕ надо.

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

Чаще всего типичные ошибки совершаются при планировании времени простоя, подсистем сервера и бюджета для его приобретения.

ВРЕМЯ ПРОСТОЯ

Недооценка и переоценка влияния этого фактора одинаково опасны - первая повлечет финансовые потери Вашей компании при простое сервера, вторая - при приобретении решения.

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

Факторы, влияющие на время простоя:

Резервирование/избыточность

Отказоустойчивость - способность решения продолжать работать при отказе любого одного из его составляющих.

Наиболее часто из строя по нашей статистике выходят (именно в порядке перечисления) жесткие диски, корпусные вентиляторы, вентиляторы на процессорах, и блоки питания. Резервирование этих компонентов даст возможность работать дальше при отказе любого из них.

Удобство ремонта и замены

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

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

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

Наличие и оперативность резервного копирования (backup).

Есть два противоположных мнения по этому поводу:

"У нас есть резервные копии - поэтому нас не волнует отказоустойчивость, если что - восстановим махом".

Поверьте - махом не восстановите. Это во-первых. Во-вторых - сотрудников Вашей компании, вынужденных перебивать документы за полдня/день/неделю, особенно при интенсивном документообороте, совершенно не обрадуют 100-200-300 иностранных денежных единиц, сэкономленных Вами на отказе от средств отказоустойчивости. Особенно если убытки от простоя и лишней работы составят тысячи и десятки тысяч этих же денежных единиц.

"Зачем нам резервное копирование, у нас же RAID с горячей заменой и прочими прибабахами есть"!

Наличие средств отказоустойчивости не заменяет и не отменяет резервного копирования.

Наличие комплектующих в запасе.

Просто прошу поверить на слово - ни один сервисный центр не в состоянии держать на гарантийном складе комплектующих столько, чтобы хватило на единовременную замену при отказах для всего, что было продано. Если не хотите бегать по всему городу в поисках вышедшей из строя железки или долго ждать ее замены на стреме, ожидая, что случится раньше - сервер упадет или замена приедет - приобретите ЗИП (те же самые винты, фаны, БП по одному). Поверьте, это сэкономит очень много нервов. Ну и, конечно же, наличие ЗИПа не заменяет и не отменяет средств обеспечения отказоустойчивости.

ПЛАНИРОВАНИЕ ПОДСИСТЕМ СЕРВЕРА.

ПРОЦЕССОР(Ы)

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

И то и другое, мягко говоря, маркетинг.

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

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

"Купим сейчас с одним процессором, потом докупим при нужде еще один/три"

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

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

ОЗУ

"Нам не нужны модули DIMM с ЕСС (error-correcting code)"

Нужны. Более того, при объеме ОЗУ более 1 ГБ иметь модули DIMM c ECC крайне рекомендуется - даже на РС. На серверах должно быть просто по определению.

"Чем больше частота тем лучше, нам нравятся не те а другие модули DIMM и т.п."

Очень опасная ошибка. Все вменяемые производители серверных материнских плат и платформ имеют собственные программы валидации (т.е. проверки работоспособности в стрессовых условиях) связок материнская плата плюс конкретные модули DIMM конкретных производителей, и списки валидированных для конкретных мат. плат модулей выкладываются на сайтах производителей материнских плат. Серверостроители, правда, иногда используют невалидированные модули - но это означает, что у них эти модули с этими материнскими платами успешно прошли проверку.

Если Вы самостоятельно выбираете DIMM для Вашего сервера - обязательно выбирайте из списка валидированных, у Вас все равно нет таких возможностей для проверки работы связок и такой статистики, как у серверостроителей и производителей материнских плат.

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

ДИСКОВАЯ ПОДСИСТЕМА

Огромное поле деятельности. Причина - очень большой разрыв в производительности между дисковой подсистемой и ОЗУ, а также - статьи 10-летней давности, воспринимаемые в отрыве от реального прогресса внутренних и внешних RAID-контроллеров.

"Нам не нужна мощная дисковая подсистема, обойдемся 2-3-4 дисками, а все, что необходимо, закэшируем в ОЗУ".

Это верно только для статичных данных, в которые годами не вносятся изменения. Если объем данных растет - рано или поздно объем наиболее часто используемых данных вылезет из объема ОЗУ, который имеет весьма существенные ограничения по масштабируемости - в отличие от внутренних и особенно (!) внешних дисковых массивов.

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

Правильный сервер всегда сбалансирован по всем подсистемам - естественно, относительно выполняемой им задачи.

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

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

"Денег у нас мало, производительный аппаратный RAID-контроллер нам не по карману".

Необходимо учесть, что самый современный и производительный внутренний (PCI-X, PCI-Express ) RAID - контроллер стоит в районе 1000 американских денег - в большинстве задач уместны более дешевые контроллеры. Но: главное отличие аппаратных RAID от лучших производителей - это наличие стандартного набора средств для восстановления работоспособности массива, никак не зависимого от операционной системы - то есть при прочих равных - у Вас гораздо меньше шансов потерять данные, имея хороший аппаратный RAID-контроллер.

"Мы купили крутой контроллер, он не должен падать/ломаться/выходить из строя".

Застрахованных от всех проблем комплектующих - любых - в природе не существует. Даже при дублировании всего в решении целиком - не бывает 100% отказоустойчивых решений. Бывают 99, (9) % - но каждая девятка после запятой стоит пары нулей справа в цене решения.

"У нас есть хороший (иногда - онлайновый) UPS, нам не нужна BBU (Battery Backup Unit - аккумулятор, сохраняющий содержимое кэша записи на контроллере при потере питания)".

Никакой UPS не гарантирует Вам 100% устойчивости к потере питания.
Отключенный WriteBack кэш снижает производительность на запись на современных контроллерах в разы.
Массив с включенным WB и при отсутствии BBU при потере питания развалится (в соответствии с женской логикой) c вероятностью 50%.

"Нам не нужна SCSI подсистема, обойдемся SATA и дисками типа WD Raptor (10K rpm)".

Слабое место SATA - работа под тяжелой нагрузкой, случайным доступом блоками небольшого размера (64 КБайт и менее), более 10-15 потоков одновременно, с высокой нагрузкой на запись. Т.е. для задач БД с более, чем 10-15 активных пользователей, от SATA-дисков мало толку.

С другой стороны, нельзя сказать, что они безнадежны:

• по IOps (Input/Output operations per second) при вышеописанном характере нагрузки один SCSI-диск 10 тыс. об/мин эквивалентен 3 SATA 7200 об/мин или 2 SATA 10 тыс. об/мин.
• существуют (сейчас) достаточно высокопроизводительные контроллеры, типа изделий Areca или 3Ware 9550 серии, близкие по производительности и объему кэша к SCSI RAID-контроллерам. Но надо учитывать, что они и по цене также близки.

В итоге - при равной производительности, SCSI и SATA дисковые подсистемы и стоить будут примерно одинаково - только SATA потребуется больше дисков и гораздо более мощный БП (не забываем, что если SCSI RAID способны раскручивать при старте по 1 винту - SATA RAID стартуют все винты разом).

"Поставим быстрый массив под данные и 1-2 отдельных жестких диска для резервного копирования".

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

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

А лучше всего - установить нормальные, штатные средства резервного копирования - лучше стримеров для этого на сегодняшний день только автоматические библиотеки с ними же в качестве приводов. Да и ассортимент стримеров довольно велик, есть, к примеру, недорогие USB внутренние и внешние стримеры от того же НР.

"Разруливание нагрузки на жесткие диски вручную эффективнее, чем RAID -контроллером".

Часто встречающаяся ошибка, основанная на статьях 10-летней давности, когда RAID-контроллеры были большими и медленными.
В результате вручную Вам придется обеспечить не только раскладку нагрузки, но и отказоустойчивость - плюс в большинстве случаев Вы поставите работоспособность дисковой подсистемы в прямую зависимость от работоспособности операционной системы.
Что касается производительности - современные RAID - контроллеры имеют производительность буквально в десятки раз выше, чем тогда, когда упомянутые статьи писались. Некоторые цифры производительности современных RAID - контроллеров можно найти здесь: http://forum.ixbt.com/topic.cgi?id=66:2208

"Поставим 1-2 диска под операционную систему, остальные в RAID под данные".

С одним диском - то же что и в случае с дисками под резервное копирование - сведете отказоустойчивость сервера к отказоустойчивости одного диска. И помните - современные операционные системы совершенно нетребовательны к дисковой подсистеме. Т.е. выделив под операционную систему даже 2 диска - Вы просто отбираете производительность этих двух дисков у задачи, под которую Вы поставили сервер. Отдельное зеркало (RAID1 из 2 дисков) под операционную систему реально оправдано в трех случаях:

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

СВЯЗКА МАТЕРИНСКАЯ ПЛАТА ПЛЮС КОРПУС.

Не зря упомянута именно связка - многие производители материнских плат проектируют их в привязке к совершенно конкретным моделям корпусов, примеры у всех на виду - Intel, Supermicro. И уже только потом валидируют чужие корпуса под свои изделия - и то не всегда.
Лучше всего использовать связки, валидированные производителем материнской платы - по крайней мере, не будет неприятных сюрпризов.
Также можно считать типичной ошибкой установку хорошие комплектующие в дешевый корпус. Во-первых, нельзя впихивать невпихуемое, во-вторых - корпус с плохими охлаждением и питанием сведет на нет все предусмотренные средства отказоустойчивости. Кстати говоря, основными причинами выхода из строя винтов, к примеру, являются именно плохие охлаждение и питание.

БЮДЖЕТ

"Вот Вам сто тысяч рублей, сделайте нам сервер"!
"У нас есть вот столько денег на решение этой задачи, больше нету"

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

"Купим груду комплектующих, а я сам (или сотрудник ИТ-отдела) соберу сервер".

Это один из самых верных путей получить неработающий сервер.

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

Обсуждение статьи: http://www.3nity.ru/viewtopic.htm?p=43793#43793

Дмитрий Кузьминский

 "Тринити"
dk@trinity.spb.ru