Типичные ошибки при планировании серверных решений

1. Время простоя 
Недооценка и переоценка влияния этого фактора одинаково опасны - первая повлечет финансовые потери Вашей компании при простое сервера, вторая - при приобретении решения. 
Если Вам кажется, что в том, что сервер постоит час-другой в рабочее время, ничего страшного - просто поверьте, что бухгалтерия, генеральный директор и другие ответственные лица и отделы Вашей компании, работа которых зависит от данных, находящихся на этом сервере, так в реальной жизни считать не будут, а ремонт сервера в условиях хронического цейтнота и непрерывной ругани удовольствия тем или тому, кто этим будет заниматься, не принесет. 
Факторы, влияющие на время простоя: 
1.1. Резервирование/избыточность 
Отказоустойчивость - способность решения продолжать работать при отказе любого одного из его составляющих. 
Наиболее часто из строя по нашей статистике выходят (именно в порядке перечисления) винты, фаны(корпусные вентиляторы и вентиляторы на процессорах), и блоки питания. Резервирование этих компонентов даст возможность работать дальше при отказе любого из них. 
1.2. Удобство ремонта и замены 
Часто слышу такую фразу - "нам горячая замена винтов/фанов/БП не нужна".  Обычно это совмещается с ситуацией, описанной в п.1. и приводит к увеличению простоя сервера или решения: никогда и ни при каких условиях нельзя полностью, полноценно восстановить и проверить работоспособность сервера за 15 минут - это, увы, аксиома. 
Сочетание средств горячей замены и резервирования даст возможность попросту избежать простоя в большинстве случаев, заменяя вышедшие из строя комплектующие просто на ходу. 
1.3. Наличие и оперативность бэкапа. 
Есть два противоложных мнения по этому поводу: 
- "у нас есть бэкап - поэтому нас не волнует отказоустойчивость, если что - восстановим махом". Поверьте - махом не восстановите. Это во-первых. Во-вторых - сотрудников Вашей компании, вынужденных перебивать документы за полдня/день/неделю, особенно при интенсивном документообороте, совершенно не обрадуют 100-200-300 убитых енотов к кэшу Вашей компании, "сэкономленных" Вами на отказе от средств отказоустойчивости. Особенно если убытки от простоя и "лишней" работы составят тысячи и десятки тысяч. 
- "зачем нам бэкап, у нас же RAID с хотсвопом и прочими прибабахами есть" - наличие средств отказоустойчивости не заменяет и не отменяет бэкап. 
1.4. Наличие комплектующих в запасе 
Просто прошу поверить на слово - ни один сервисный центр не в состоянии держать на гарантийном складе комплектующих столько, чтобы хватило на единовременную замену при отказах для всего, что было продано. Если не хотите бегать по всему городу в поисках вышедшей из строя железки или долго ждать ее замены "на стреме", ожидая, что случится раньше - сервер упадет или замена приедет - приобретите ЗИП (те же самые винты, фаны, БП по одному) . Поверьте, это сэкономит очень много нервов. Ну и, конечно же, наличие ЗИПа не заменяет и не отменяет средств обеспечения отказоустойчивости. 

2. Планирование подсистем сервера. 
2.1. Процессор(ы) 
"Процессоры и платформы фирмы ХХХ рулез, остальные плохие"  
"Процессоры и платформы одной фирмы за сильно меньшую цену обеспечивают сильно лучшие эксплуатационные характеристики - производительность, энергопотребление и тепловыделение и т.п." 
И то и другое, мягко говоря, маркетинг  
Никакой вендор не станет продавать свой товар дешевле, чем потребители готовы за него платить. Также товары со сравнимой ценой имеют сравнимые же эксплуатационные характеристики. 
Единственное, что реально может повлиять на выбор процессора и платформы - это лучшая оптимизация ПО под ту или иную архитектуру. Наличие/отсутствие такой оптимизации лучше всего выяснить в документации и на сайте вендора ПО. 

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

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

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

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

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

- "нам не нужна мощная дисковая подсистема, обойдемся 2-3-4 дисками, а все, что необходимо, закэшируем в ОЗУ" 
Это верно только для статичных данных, в которые годами не вносятся изменения. Если объем данных растет - рано или поздно объем наиболее часто используемых данных вылезет из объема ОЗУ, который имеет весьма существенные ограничения по масштабируемости - в отличие от внутренних и особенно (!) внешних дисковых массивов. В современных условиях, когда на документооборот в электронном виде завязан бизнес целиком, это будет скорее рано, чем поздно. И приведет это к жестоким тормозам в работе сервера, как минимум, и к все тому же простою - как максимум. 
Правильный сервер всегда сбалансирован по всем подсистемам - естественно, относительно выполняемой им задачи. 

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

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

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

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

И несколько спорных моментов. 

- "нам не нужна 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 10K об/мин. 
- существуют (сейчас) достаточно высокопроизводительные контроллеры, типа изделий Areca или 3Ware 9550 серии, близкие по производительности и объему кэша к SCSI RAID-контроллерам. Но надо учитывать, что они и по цене также близки. 
В итоге - при равной производительности, SCSI и SATA дисковые подсистемы и стоить будут примерно одинаково - только SATA потребуется больше дисков и гораздо более мощный БП (не забываем, что если  SCSI RAID способны раскручивать при старте по 1 винту - SATA RAID стартуют все винты разом). 

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

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

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

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

Источник:http://3nity.ru

назад