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

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

Модераторы: Trinity admin`s, Free-lance moderator`s

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

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

Сообщение a_shats » 17 июл 2006, 17:26

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

По мере возможностей, буду дописывать дальше.
Последний раз редактировалось a_shats 17 июл 2006, 20:40, всего редактировалось 1 раз.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 17 июл 2006, 18:07

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

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

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

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

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

2.3. Дисковая подсистема
Огромное поле деятельности :gigi: Причина - очень большой разрыв в производительности между дисковой подсистемой и ОЗУ, а также - статьи 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 при потере питания развалится (в соответствии с женской логикой :gigi:) 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-контроллеры были большими и медленными :gigi:
В результате вручную Вам придется обеспечить не только раскладку нагрузки, но и отказоустойчивость - плюс в большинстве случаев Вы поставите работоспособность дисковой подсистемы в прямую зависимость от работоспособности ОС.
Что касается производительности - современные RAID-контроллеры имеют производительность буквально в десятки раз выше, чем тогда, когда упомянутые статьи писались. Некоторые цифры производительности современных RAID можно найти здесь.

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

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

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 17 июл 2006, 18:17

Буду дописывать по мере вспоминания этих самых типичных ошибок :)
Обновил про винты "под бэкап" по предложению ALEX_SE
Обновил п.2.3, по разруливанию нагрузок на винты вручную.
Добавил п.2.4.
Обновил п. 2.1. о процессорах, по предложению Tert
Обновил п. 2.3 по предложению ReWire
Обновил п. 2.3 про отдельные винты под ОС.
Последний раз редактировалось a_shats 18 июл 2006, 15:26, всего редактировалось 4 раза.

Аватара пользователя
Tert
Advanced member
Сообщения: 4233
Зарегистрирован: 19 янв 2003, 08:09
Откуда: Москва
Контактная информация:

Сообщение Tert » 17 июл 2006, 19:31

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

P.S. Классный FAQ :D  Мне понравился...

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 17 июл 2006, 20:16

Сделал :)
Стараимси...  :smoke: :gigi:

Аватара пользователя
Kirill Tkachev
Advanced member
Сообщения: 481
Зарегистрирован: 08 июл 2004, 13:37
Откуда: Saint-Petersburg
Контактная информация:

Сообщение Kirill Tkachev » 18 июл 2006, 15:43

Отличная вещь, есть теперь куда народу начальство тыкать. 8)
Только в changelog'e писать бы еще даты изменений. ;)

Phoenix
Junior member
Сообщения: 9
Зарегистрирован: 10 ноя 2005, 13:46
Откуда: Москва

Сообщение Phoenix » 21 июл 2006, 12:07

Очень часто экономятся гроши на дополнительной системе охлаждения внутри сервера. Но если температура в серверной высокая то и внутри сервера греются сильнее. У меня сервер работал как часы, до тех пор пока не отключался кондиционер. Причем температура воздуха повышалась всего на 3-4 градуса, а в результате, два часа и все - blue death of screen от перегрева. Пара дополнительных вентиляторов - и как рукой сняло.
  Есть еще одна маленькая деталь на которую почему-то редко кто обращает внимание - пылезащищенность сервера. Фаны чаще всего выходят из строя именно от загрязнения, а уж от повышенной температуры летят винты и БП. Я так думаю! (с) :lol:
 Приведу один пример. У меня стоял сервер с пылезащитным фильтром. Пока в серверной была чистота и порядок я чистил фильтр раз в 2-3 месяца. Но в один прекрасный день рядом с моей стойкой начали монтировать свое оборудование телефонеры. Две недели была такая грязюка - мама не горюй. Вот тут-то я и оценил этот маленький прямоугольник из паралона. Видели бы вы , что было внутри сервака, корпус которого не имел пылезащиты! :shock:

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 21 июл 2006, 12:19

FAQ преобразован в статью:
http://www.trinity.su/news/363.htm
Обсуждать предлагаю здесь же.

Wisky
Power member
Сообщения: 49
Зарегистрирован: 12 дек 2005, 03:54
Откуда: Moscow
Контактная информация:

Сообщение Wisky » 15 май 2007, 10:25

Можно дополнить ФАК по шумоизоляции?
работаем со звуком, видео - а минимизировать шум от корпуса+массива получилось только своими, кустарными силами

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 15 май 2007, 11:54

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

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 01 авг 2007, 13:48

Флейм с igor по поводу стиля статей -в этой теме, здесь все посты не по теме будут удаляться.

Аватара пользователя
itman_sa
Advanced member
Сообщения: 116
Зарегистрирован: 07 июн 2006, 09:58
Откуда: Новороссийск
Контактная информация:

Сообщение itman_sa » 10 окт 2007, 10:44

Прошу добавит минусы построения серверов на "не серверном оборудовании", а то в последнее время развелось много сисадминов строящих серверы "немного дешевле".

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 22 ноя 2007, 13:26

Новый адрес статьи:
http://www.trinity.su/articles.php?nid=2
itman_sa
Вообще-то, это тема отдельной статьи, причем тема скользкая и требующая большого количества реальных цифирей (не MTBF - а статистики отказов), которые в свободном доступе появляются редко.

vmarkovsky
Junior member
Сообщения: 4
Зарегистрирован: 11 дек 2007, 23:20
Откуда: UA, Lviv

Сообщение vmarkovsky » 11 дек 2007, 23:28

Wisky писал(а):Можно дополнить ФАК по шумоизоляции?
работаем со звуком, видео - а минимизировать шум от корпуса+массива получилось только своими, кустарными силами
Хм  Вообще говоря, в серверах задача минимизации шума практически никогда не ставится - это только в РС, ибо серверы по определению рядом с работающими людьми находиться не должны, для того есть серверная.
А если серверная за кирпичной стеной и все равно слышно шум кулеров?
Так что я за FAQ по шумоизоляции серверных!

Аватара пользователя
setar
Site Admin
Site Admin
Сообщения: 1990
Зарегистрирован: 22 авг 2002, 12:03
Откуда: St. Petersburg

Сообщение setar » 14 дек 2007, 11:01

vmarkovsky писал(а):
Wisky писал(а):Можно дополнить ФАК по шумоизоляции?
работаем со звуком, видео - а минимизировать шум от корпуса+массива получилось только своими, кустарными силами
Хм  Вообще говоря, в серверах задача минимизации шума практически никогда не ставится - это только в РС, ибо серверы по определению рядом с работающими людьми находиться не должны, для того есть серверная.
А если серверная за кирпичной стеной и все равно слышно шум кулеров?
Так что я за FAQ по шумоизоляции серверных!
8)  малость пошучу, но в каждой шутке есть доля ... шутки.

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

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

Ответить

Вернуться в «Серверы - FAQ»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя