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

Основные моменты, требующие внимания при выборе сервера

Задачи

Основной и главный фактор выбора — тип и характер нагрузки. Исходя из них подбираются общие параметры конфигурации: количество и характеристики CPU, объем оперативной памяти, параметры дисковой подсистемы и т.п. Очевидно, что конфигурация нагруженного сервера СУБД будет отличаться от контроллера домена или хоста виртуализации. Здесь обычно отталкиваются от системных требований конкретного ПО для необходимой нагрузки, а также опыта в оценке требуемой производительности для необходимого софта. Если говорить о каких-то советах, то для хоста виртуализации лучше сконфигурировать сервер с максимальным для бюджета объёмом оперативной памяти (её все равно вскоре станет мало :)). Для сервера СУБД лучше позаботиться о производительности процессоров и очень быстрой как по IOPS, так и по минимальным задержкам дисковой подсистеме (если, конечно, планируется использование локальных дисков). Сервер файлового хранилища стоит выбрать с большим количеством дисковых слотов и достойным контроллером RAID.

Расширяемость

Несмотря на стандартную практику добавления определённого запаса по характеристикам при покупке сервера, нередки ситуации, когда незапланированный рост нагрузки требует больше ресурсов, чем имеется. В таком случае предусмотрительность в вопросе дальнейшего апгрейда поможет обойтись существенно меньшими затратами. В первую очередь это касается объёма оперативной памяти (количество свободных слотов и утилизация каналов), количества дисков и портов расширения PCIe для добавления какого-нибудь сетевого адаптера, HBA, nVMe SSD и т.п. Однако, крайне не рекомендую, к примеру, покупать двухсокетный сервер с одним процессором, поскольку часто бывают банальные ситуации, когда второй процессор для апгрейда уже не купить (за давностью лет) нигде кроме eBay. Экономия средств на старте превращается в переплату. Также многие заказчики могут в последствии столкнуться с тем, что ревизия и степпинг процессоров отличаются, и возникают странные зависания, ошибки и прочие неприятности, что, впрочем, обычно решается обновлением BIOS/UEFI до свежей версии, при наличии таковой, конечно. И если вендоры брендового железа стараются обновлять прошивки в течение всего цикла поддержки сервера, то в случае с самосборным решением и около-noname производителями комплектующих (в первую очередь, материнских плат) вполне можно остаться у разбитого корыта.

RAS

Reliability, Availability, Serviceability — термин введён компанией IBM и описывает надёжность системы в целом, как она обеспечивает непрерывность возложенной на неё работы. При необходимости наличия достаточно высоких показателей RAS стоит смотреть в сторону машин серьёзных брендов, поскольку в них данным особенностям уделяется довольно большое внимание, в отличие от брендов нижнего сегмента или самостоятельной сборки из компонентов.

Reliability (или, по-русски, надёжность)

Подразумевает возможность системы самостоятельно устранять сбои без влияния на конечный результат. К данной характеристике относятся разнообразные технологии, применяемые практически во всех компонентах: как типовые для всех определение ошибок в инструкциях процессоров и оповещение об этом операционной системе (к примеру, MCA от Intel), коррекция ошибок в оперативной памяти (ECC, scrubbing), так и вендор-специфичные вроде предиктивного анализа на уровне сервисного процессора (PFA).

Availability (доступность)

Определяет как долго система находится в работоспособном состоянии относительно запланированного времени. Доступность повышается за счёт использования качественных комплектующих, резервирования критичного оборудования (блоки питания, вентиляторы, HBA), общего запаса прочности сервера для конкретных условий эксплуатации. Типичный анти-пример – десктопные SSD под серверной нагрузкой: да, это приблизительно так же быстро, да, это серьёзно дешевле, но при превышении порога DWPD (который крайне низок у десктопных накопителей), SSD запросто выходят из строя, и хорошо, если подход администратора и стечение обстоятельств привели только к downtime, а не к потере данных.

Serviceability (простота и скорость обслуживания)

Даёт возможность увеличить доступность в случае, если сбой все же произошёл, за счёт быстрого восстановления. Для этого используется большое количество компонентов с горячей заменой, удобные рельсы с возможностью обслуживания без прерывания работы, различные диагностические решения как доступные по сети через сервисный процессор, так и расположенные на корпусе сервера — они позволяют быстро определить сбойный компонент. Некоторые производители добавляют функционал «Call Home», который автоматически сообщает о сбое в техническую поддержку, тем самым сокращая время восстановления. Если критичность сервисов, располагающихся на сервере, достаточно высока, стоит уделить RAS серьезное внимание.

Окружающие условия

Сюда относятся параметры питания (мощность и эффективность БП), охлаждения (качество исполнения системы охлаждения, возможность работы при повышенных температурах, в том числе и без потери гарантии), датчики температуры внутри корпуса, форм-фактор (который также влияет на исполнение и эффективность охлаждения — актуально при высокой плотности размещения). При наличии «горячих» компонентов (CPU с высоким TDP, GPU и т. п.) не нужно гнаться за малым форм-фактором без явной необходимости высокоплотного размещения, лучше выбрать что-нибудь типоразмера 2U или даже больше.

Совместимость

Наличие сервера и компонентов в HCL нужного производителя позволит избежать неприятных ситуаций, связанных с запуском ПО. Также, запрос на поддержку к вендору ПО может как превратиться в пинг-понг между вендорами железа и софта, так и вовсе может быть отклонён в случае запуска на неподдерживаемом оборудовании. Да и в целом, куда приятнее получить работающее из коробки решение, нежели заниматься перепаковкой образа гипервизора для того, чтобы положить туда драйвер RAID-контроллера (этот пример — отсылка к совместимости ESXi и контроллеров Adaptec, которая формально есть, но требует предварительных ласк). Поэтому, если задача и ПО требуют совместимости с железом – данный пункт требует тщательного подбора комплектующих (с серверами крупных производителей с этой точки зрения все очень даже просто – они присутствуют в HCL практически всех компаний-разработчиков ПО как покомпонентно, так и целиком).

Управление

Практически все серверы оснащены контроллерами удалённого управления, предоставляющими интерфейс, совместимый с IPMI и/или web-консоль. В зависимости от вендора, контроллеры могут обладать различным функционалом, от монтирования образов по сети, автоматической установки ОС и централизованного обновления прошивок до полноценного Life-cycle Management, что значительно упрощает и ускоряет ввод в строй новых серверов и их дальнейшее обслуживание. Степень внимания к данному пункту зависит от величины парка серверов и потребностей в удобстве удалённого управления. Честно говоря, всегда закладываю в конфигурацию опциональные лицензии на дополнительный функционал управления (за исключением LCM без явного указания потребностей в нем), поскольку это банально удобно, а удобство обслуживания серьёзно сокращает его время.

Производительность

На первый взгляд, странный пункт: ведь в серверах разных вендоров используются одни и те же процессоры, оперативная память, диски и т. п. Однако, если «в лоб» измерить производительность серверов разных производителей в одинаковых конфигурациях, можно получить неодинаковые результаты. В первую очередь, это объясняется (но не ограничивается) различными настройками и оптимизациями на уровне firmware. Для понимания уровня производительности относительно конкурентных предложений можно обратиться к серверным бенчмаркам (например, VMmark от VMware).

Гарантия и сервис

Многие вендоры предлагают сервисные пакеты, которые дают возможность быстро выявлять причину аппаратного сбоя и устранять её с помощью замены компонентов. Пакеты отличаются по гарантийным и сервисным срокам, а также времени реакции и восстановления. Также, различается доступность запчастей на сервисных складах после снятия конкретной модели с производства. В случае самостоятельной сборки приходится либо держать у себя ЗИП, либо полагаться на поставщика/сборщика оборудования в вопросах доступности запчастей на складе и длительности их доставки.

Заключение

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

Также вы можете подписаться на наши каналы (YouTube, VK, Telegram), чтобы не пропустить новые статьи, курсы и семинары.