Привет, Хабр! Меня зовут Ярослав, я стажер инженерно-технического отдела в Selectel. И несколько лет назад у меня была мечта — сделать домашний дата-центр. Я ее исполнил и хочу предупредить: не повторяйте моих ошибок, сохраните психику.
В статье делюсь опытом проектирования и сборки домашнего дата-центра. А также рассказываю, как случайно не сжечь серверный шкаф и за что провайдеры могут подать в суд. Подробности под катом.
Дисклеймер: Я называю свой пет-проект дата-центром, потому что, помимо нескольких серверов, у меня целая инфраструктурная обвязка в виде сетевого оборудования, систем отказоустойчивой работы и даже СКУД. Естественно, он очень далек от того, что представляют собой настоящие дата-центры, но я все равно буду называть его в тексте именно так. Живите с этим! 🙂
Зачем мне дата-центр
Просто так идея о возведении дата-центра не возникает. Если вспомнить историю Selectel, то первый дата-центр появился для хостинга «Вконтакте». Почти то же самое случилось с моим пет-проектом. Только заказчиком был не «Вконтакте», а я не был крупным инвестором.
У меня было желание — изучить профессиональное сетевое оборудование, чтобы перейти на него со своего домашнего роутера. Изначально цель была построить проводной интернет в квартире. Но потом я задался вопросом: могу ли я самостоятельно сделать серверную с корпоративным качеством сервиса?
Цель превратилась в челлендж по развертыванию собственной серверной инфраструктуры с минимизацией влияния различных провайдеров.
Закупка сетевого оборудования
Коммутаторы
Бюджет в 70 000 рублей меня ограничивал: я не мог себе позволить коммутаторы от Cisco, Juniper, Huawei, H3C или Brocade. Наиболее оптимальным вариантом в 2017 году — именно тогда я начал «строительство» дата-центра — казалась связка из двух управляемых L3-стекируемых коммутаторов D-link DGS-1510-28. Стоимость одной шутки — 16 000.
Можно ли было найти модель дешевле? Да, но у DGS-1510-28 были аплинк-порты на 10G, которые, как я думал, понадобятся. Но оказалось, что трафик внутри сети не превышает даже 1 Гбит/с.
DGS-1510-28. Источник
Зачем нужно было два коммутатора?
Сначала я хотел проложить по квартире витую пару и установить rj45-розетки в каждой комнате. Задумка была в том, чтобы все стационарные устройства подключались по кабелю, а смартфоны — по беспроводной сети.
rj45. Источник
У идеи был недостаток: нужно более 24 портов на коммутаторе, чтобы подключить все устройства, розетки и резервы. Поэтому пришлось докупать второй коммутатор. В итоге я объединил два коммутатора в одно логическое устройство — получился Stack. Но позже я отказался от этой идеи.
Роутер
В качестве роутера я использовал Mikrotik RB3011. Тогда, в 2017 году, я его взял за 15 000.
Mikrotik RB3011. Источник
Серверное помещение
Отчасти идею удалось реализовать: стационарные устройства получили проводное подключение, а в некоторые комнаты были проведены дополнительные линии с розетками. Но большую часть розеток я так и не использовал. Неправильный расчет кабельной системы — мой первый факап.
Первая площадка
Унывать было некогда, и я продолжил работу над первой версией серверной.
Рекурсия. Фотографирую сам себя через камеру видеонаблюдения. На фото — первое помещение
Тогда о стойках не было и речи, но получилась вполне гиковская сборка из оборудования. Она была до неприличия колхозной: кабель-менеджмент напрочь отсутствовал, коммутаторы были скреплены деревянным бруском. А в качестве сервера я использовал свой компьютер.
Первый сервер и шкаф
Когда пришло осознание, что пора бы перестать мучить компьютер, я купил сервер — HPE ProLiant DL360p Gen8. Для него докупил подержанный шкаф на 32 юнита.
Переезд на вторую площадку
Водяное охлаждение в серверных платформах вот уже несколько лет набирает популярность. Но это решение не для простых обывателей. Поэтому я использовал воздушное охлаждение в своих серверах.
Была проблема — сильный шум от вентиляторов. Не хотел, чтобы меня проклинали соседи по квартире, и понял, что серверу нужно переехать.
Я перенес сервера на нежилую площадку. Только так я мог повысить шансы бесперебойной работы оборудования, поскольку не было соседей, которые могли случайно отключить электричество.
Площадка внушительная — целых 4 квадратных метра. Пожалуйста, не спрашивайте, что это за помещение. Оно нежилое — и это главное.
Возможно, эти тексты тоже вас заинтересуют:
→ Залогиниться из России через Турцию — без VPN. Обновление геолокаций IP с помощью Geofeed
→ Объединяй коммутаторы и властвуй — сравниваем Stack и MLAG
→ Сетевое резервирование в дата-центрах: решаем задачку про двух велосипедистов
Шумоизоляция
Я все равно решил избавиться от «серверного воя» и обклеил уже новый серверный шкаф автомобильной шумоизоляцией.
Через несколько дней я понял, что мое решение не самое разумное. У него есть пара недостатков:
- Ноль эффекта. Лопасти вентиляторов не умолкали. Возможно, это из-за вентиляционных отверстий или плохих шумоизоляционных свойств материала.
- У материала высокая горючесть. Шумоизоляция неплохо так горит. В условиях серверного помещения это недопустимо.
Шумоизоляцию нужно было снять, притом как можно быстрее. Но и с этим возникли проблемы: материал намертво приклеился к серверному шкафу. До сих пор не могу снять «камуфляж», который остался после зачистки. Вот бы это было единственной заботой при проектировании…
Резервное питание
Для бесперебойного электроснабжения можно использовать источники бесперебойного питания (ИБП) трех типов — резервные, линейно-интерактивные и онлайн-ИБП.
Когда серверов у меня еще не было, я использовал офисные ИБП со встроенными аккумуляторными батареями (АКБ). Для питания сетевого оборудования, которое потребляет минимум электричества, они вполне подходили.
Когда же я установил серверы, к ИБП появились дополнительные требования:
- Нужно регулировать входное напряжение и фильтровать его от помех.
- Емкости АКБ должно быть достаточно для питания серверов.
Решение
Я выбрал недорогой линейно-интерактивный ИБП Ippon Smart Winner 1500 мощностью 1500 ВА и тремя встроенными АКБ по 9 А/ч на 12В. К нему можно было подключить дополнительные блоки АКБ.
Увеличение емкости ИБП
Мощности выбранного ИБП хватило для электропитания двух серверов HPE ProLiant. Но возникли проблемы с емкостью и продолжительностью работы АКБ.
Я попробовал решить проблему за счет приобретения дополнительного блока АКБ. И это помогло: емкости ИБП хватает на 2 часа работы сервера. Так как на серверах не хостятся коммерческие сервисы, этого достаточно.
Планы
В будущем планирую перейти на онлайн-ИБП. Они используют двойное преобразование электроэнергии: из переменного тока в постоянный и обратно. Оборудование получает «чистую электроэнергию» — ток, который стремится к правильной синусоидальной форме. На мой взгляд, это лучший способ организации электропитания серверного оборудования. Но и самый дорогой. Кстати, именно его мы используем в Selectel.
Возможно, когда-нибудь я внедрю онлайн-ИБП в свой дата-центр. Если у вас есть опыт использования такого оборудования — напишите в комментариях.
Пример онлайн-ИБП с подключенными АКБ
Физическое резервирование аплинков
Для стабильной связи дата-центра с интернетом нужно резервировать аплинки — соединения от роутеров во «внешний мир». Есть ряд особенностей, которые нужно учитывать.
Юридическая ответственность
В качестве аплинков нужно использовать каналы с широкополосной передачей данных. Но есть нюанс: интернет-провайдеры не разрешают использовать аплинки для коммерческих целей.
Не рекомендую сдавать в аренду домашние серверы: можно нарваться на судебный иск.
Отказоустойчивые аплинки
Почти в каждом многоквартирном доме есть несколько интернет-провайдеров. Это хорошо: можно выбрать два независимых провайдера и организовать отказоустойчивый выход в интернет.
Но важно, чтобы провайдеры были независимыми, с разным оборудованием и линиями связи. Обратное бывает, когда один интернет-провайдер поглощает другого: тогда, если у одного провайдера сломается оборудование, велика вероятность, что у второго провайдера тоже будут сбои. Толку от такого резервирования нет.
Как узнать, какие провайдеры независимы друг от друга — открытый вопрос. Напишите в комментариях, если есть идеи.
Резервный оптический аплинк
Иногда провайдеры падают из-за электропитания коммутаторов, которые подключены к общедомовой электросети: отключили в доме электричество — бах — аплинки не работают. Чтобы это не отразилось на дата-центре, я использую один PON-аплинк от провайдера.
PON (Passive Optical Network) — технология деления и передачи сигнала от потребителя по оптическому волокну.
У PON-аплинков есть преимущество: активное оборудование, к которому протянуто оптоволокно, зарезервировано провайдерами по питанию от другой сети, которая не зависит от электроснабжения дома. Если в доме погаснет свет, соединение дата-центра с интернетом будет работать как минимум 2 часа, пока не разрядится ИБП. Или пока кто-то не сломает резервный PON-аплинк.
Переключения между IP-адресами
На следующем этапе нужно было настроить доступ к серверам через интернет.
Но и здесь было препятствие: каждый провайдер выдал по одному «белому» IP, а пакеты можно отправлять только через конкретный адрес. То есть нужно было научиться балансировать трафик и переключаться между IP-адресами. Я нашел два пути решения этой задачи.
DNS с минимальным TTL
Изначально планировал передавать через одну запись DNS сразу несколько IP-адресов. Но тогда, если пользователь отправит запрос к DNS-серверу, в ответ он может получить «пачку адресов». А дальше неизвестно, что с ней сделает ОС клиента: она может постучаться по произвольному адресу и, например, получить ответ «Ресурс недоступен».
Чтобы избежать таких ошибок, я загрузил на роутер скрипт. За его основу взял код из github-проекта. Но есть отличие: я запускаю скрипт не по расписанию, а через утилиту netwatch — она отправляет эхо-запросы (ping) через аплинки и при падении одного из них запускает скрипт. Так Mikrotik отслеживает состояние каналов и через API DNS-сервис меняет IP-адрес на актуальный.
Минимальное время жизни записи (TTL) нужно для того, чтобы после переключения на резервный канал запись со старым IP долго не жила в кешах устройств — это может привести к ошибкам вроде 404 — и удалялась. Из минусов:
- долгое время переключения на резерв, равное значению TTL,
- необходимость поддержки API DNS-сервисом.
В качестве DNS провайдера я использую сервис Cloudflare, так как он поддерживает API и есть возможность указать минимальный TTL, равный 1 минуте.
Но есть и другие варианты.
Промежуточный хост-сервер
Для балансировки трафика между двумя IP-адресами можно использовать хост-сервер: пользователь отправляет трафик на надежный хост, который определяет, на какой IP его перенаправить. Есть два способа организации такого сценария.
VPN-туннель
Идея в том, чтобы пользователи обращались к хосту, от которого поднят VPN-туннель до моего дата-центра. Данный хост перенаправляет пакеты из интернета на сервер дата-центра через туннель. Для преобразования адресов на частные используется DST-NAT. Но есть минус — большая нагрузка на хост-сервер из-за шифрования во время передачи через VPN-туннель.
Обратный прокси-сервер
Чтобы снизить нагрузку, можно использовать обратный прокси-сервер вместо VPN-туннеля.
Обратный прокси-сервер — это балансировщик, который перенаправляет весь HTTP-трафик на web-серверы внутри сети, учитывая доступность и загруженность каждого из серверов.
Я пробовал организовать обратный прокси-сервер. Он анализировал доступность внешних адресов с помощью специальных запросов на каждый из внешних IP и «смотрел», какой из них актуален на данный момент.
Резервирование аплинков хост-сервера
У вас мог появиться вопрос: «Разве для хост-сервера не нужно тоже резервировать аплинки и плодить IP-адреса?»
Самостоятельно — не нужно. Хост-сервер можно реализовать на виртуальной машине, bare metal-сервере или роутере. В случае с виртуальной машиной за резервирование ответственен облачный провайдер. А для резервирования физического сервера достаточно заказать услугу MC-LAG.
Сетевая инфраструктура
Со всеми резервными и не резервными аплинками получилась такая топология сети дата-центра:
Откуда второй роутер?
На схеме видно, что в сети работают два роутера: основной и резервный. Когда я переезжал на вторую площадку, я купил второй роутер — Mikrotik hEX. Он слабее, чем Mikrotik RB3011. Но это не просто так: скорость канала от резервного провайдера меньше, чем от основного, — всего 100 Мбит/с. С такой скоростью hEX справляется без проблем.
Для резервирования шлюза на роутерах настроен протокол VRRP. О том, как он работает, можно прочитать в статье.
Резервное подключение серверов
Чтобы не резервировать коммутаторы, я решил включить серверы напрямую в роутеры и настроить MC-LAG (MLAG). Портов на роутерах хватило для включения двух серверов. Сами же коммутаторы использовал для включения в сеть остальной периферии дата-центра: видеокамеры, контроллера и прочего оборудования.
Мониторинг
На площадке я нахожусь не всегда, поэтому нужно было собрать систему для удаленного мониторинга оборудования.
Электроэнергия
Для учета электричества я использую электросчетчик с последовательным интерфейсом, который подключен к Ethernet-преобразователю RS-485.
Преобразователь нужен для передачи данных со счетчика на виртуальную машину — в систему мониторинга Zabbix. Это open source-программа для отслеживания статусов оборудования.
Охранно-пожарная сигнализация
В помещении я разместил контроллер SNR ERD-4s-GSM. К нему я подключил магнито-контактные датчики и дымовой извещатель.
Контроллер можно мониторить по локальной сети и через SMS-оповещения: если в серверной что-то загорелось, на телефон придет сообщение. В дополнение к охранной сигнализации я использую видеонаблюдение.
Распределение питания
Для управления питанием серверов собрал «аналог» PDU из трех управляемых розеток со встроенными реле, которые я подключил к выходам контроллера. Через них можно управлять электропитанием блока вентиляторов и некоторыми сетевыми устройствами: коммутаторами и вентиляторами.
Можно ли назвать домашний дата-центр полноценным
Я доволен тем, что получилось. В будущем планирую перевезти серверы на дачный участок. Представляю, как буду летом отдыхать в холодном коридоре, а зимой — в горячем.
Но для коммерческих проектов и дачный вариант дата-центра использовать нельзя. Я уже говорил о юридической ответственности. Но есть и вторая причина — технические ограничения. Вот некоторые из них:
— Для охлаждения большого количества серверов нужны мощные кондиционеры.
— Нельзя превышать лимит по потребляемой электроэнергии.
— В домашнем дата-центре нет дежурного персонала.
Для серьезных проектов рекомендую обращаться за услугами к настоящим дата-центрам — это надежней и выгодней, чем строить свою инфраструктуру на коленке.
Не знаю, во что превратится мой проект через несколько лет. Если он разрастется настолько, что его выкупит Selectel, вы узнаете об этом здесь, в блоге на Хабре.
