Хочу рассказать о своем видении как построить сервер обладающий достаточно высоким уровнем надежности, используя ненадежное оборудование. Этот взгляд не претендует ни на уникальность, ни на звание «серебрянной пули» — способов масса, и каждый выбирает для себя наиболее подходящий, в соответствии с текущими условиями. Я лишь постарался экстраполировать свой более чем десятилетний опыт работы системным администратором в этой статье.

Надежность вашего сервера

Здесь описаны лишь общие представления о концепции, без мануалов и пошаговых how-to. Конкретные решения будут описаны в дальнейших статьях.

Для начала договоримся о том, что нужно построить сервер, обладающий достаточно высокой степенью надежности, имея достаточно ограниченный бюджет (без возможности покупки дорогих брэндовых решений, с круглосуточной 24*7*365 поддержкой). Под надежностью мы понимаем сохранность данных + минимальное время простоя сервера.

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

  1. Пользовательские данные — все данные, которые нельзя установить с дистрибутивов ПО.
  2. Системные данные — любые данные, файлы операционной системы и программного обеспечения, которые можно скачать/переписать/восстановить с дистрибутива или восстановить из архива (далее).
  3. Железо — аппаратное обеспечение. Жесткие диски, процессор, память, и т. д.

Начнем с ненадежного железа, как с главной причины написания этой статьи. Железо ломается, и точка. С этим ничего нельзя сделать.

И это даже не всегда зависит от его стоимости. Я видел и много самосбора работающего пятилетками, и дорогие сервера постоянно выходящие из строя. Что мы четко должны понимать? Железо рано или поздно сломается, но его можно заменить, и это самая приятная часть. Нам нужно быть готовым к поломке оборудования, и возможности быстро и легко перенести всю логику работы сервера (включая пользовательские данные) на другой подобный сервер.

Сохранность данных на сервере

Данные — самая важная часть любого сервера (кроме либо абсолютно нового, еще не запущенного в эксплуатацию, либо кроме абсолютно старого, представляющего только реликтовую ценность). Данные нужно беречь. Каким образом?

Я не зря разделил данные на системные и пользовательские. В случае если «все пропало» — системные данные восстановить значительно проще и быстрее чем пользовательские, накопленные годами. Самый простой и очевидный способ сохранения пользовательских данных — хранить их на рэйд-массиве. Это давно известно, и тут я не скажу ничего нового, лишь на всякий случай скажу что рэйд-массив уровня 0 — это не рэйд вообще, и теряя один диск — мы автоматически теряем весь массив со всеми данными.

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

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

По поводу системных данных — существует две идеи повышения надежности:

  1. Виртуализация Эта идея подразумевает установку гипервизора виртуальных машин, под которым работает виртуальная машина с установленным и настроенным сервером. Плюсом такого подхода является возможность очень быстрого мигрирования сервера на любой другой сервер — достаточно лишь установить на новом сервере гипервизор, и скопировать на него файл-контейнер с нашим виртуальным сервером. Оборудование на новом сервере может сильно отличаться от старого, и изменение конфигурации под новый сервер может занять много времени и нервов, виртуализация же скрывает отличия, и позволяет действительно быстро перенести виртуальный сервер с одного физического сервера на другой. Так же нельзя не отметить легкость бэкапа и восстановления — заключающуюся в простом копировании файла-контейнера на любой носитель, и возможность восстановления резервной копии за любой момент времени с легкостью копирования файла. Минусом можно отметить небольшую потерю производительности (обычно 3-10%), но за удобство приходится платить.
  2. Система на флэшке Флэш-память в последнее время стала достаточно дешевой и вполне надежной, что делает ее очень привлекательной для размещения не ней операционной системы и файлов программного обеспечения. Здесь плюсом является удобство сохранения резервных копий — можно делать и хранить несколько идентичных флэшек с настроенными ОС и ПО, и в случае поломки флэшки — просто заменить ее другой.

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

Никто не запрещает установить ОС на жесткий диск, без использования виртуализации, но тогда будет сложнее и дольше «сменить железо», и восстановить из бэкапа.

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