Как мы строили свой мини ЦОД. Часть 1 — Colocation
Здравствуйте коллеги и жители Хабра. Хотим рассказать Вам историю одной небольшой компании от начала её становления до текущих реалий. Хотим сразу сказать, что данный материал сделан для людей, которым интересна эта тематика. Прежде чем это написать (и задолго до этого) мы пересмотрели множество публикаций на Хабре о строительстве ЦОДов и это очень помогло нам в реализации наших идей. Публикация будет разделена на несколько этапов нашей работы, от аренды шкафа до финала постройки собственного мини-цода. Надеюсь и эта статья поможет хотя бы одному человеку. Поехали!
Поехали
В 2015 году, в Украине была создана хостинг-компания с большими амбициями на будущее и фактическим отсутствием стартового капитала. Оборудование мы арендовали в Москве, у одного из известных провайдеров (и по знакомству), это и дало нам начало развития. Благодаря нашему опыту и отчасти везению, уже в первые месяцы мы набрали достаточно клиентов, чтобы купить собственное оборудование и обзавестись хорошими связями.
Мы долго выбирали оборудование, которое нам нужно для собственных целей, выбирали сначала по параметрам цена/качество, но к сожалению большинство известных брендов (hp, dell, supermicro, ibm) все очень неплохи по качеству и схожи по цене.
Тогда мы пошли другим путем, выбирали из того что есть в Украине в наличии в больших количествах (на случай поломок или замены) и выбрали HP. Супермикро (как нам казалось) очень неплохо конфигурируются, но к сожалению их цена в Украине превышала всякий адекватный смысл. Да и запчастей было не так много. Так мы и выбрали, то что выбрали.
Первое железо
Мы арендовали шкаф в Днепропетровском дата-центре и приобрели Cisco 4948 10GE (на вырост) и первые три сервера HP Gen 6.
Выбор оборудования HP, впоследствии нам очень помог, за счет своего низкого энергопотребления. Ну а дальше, пошло-поехало. Приобрели управляемые розетки (PDU), они нам были важны для отсчета энергопотребления и управления серверами (авто-инсталл).
Уже потом мы поняли что взяли не те PDU которые управляются, а просто измерительные. Но благо HP имеет встроенное iLO (IPMI) и это нас спасло. Мы сделали всю автоматизацию системы при помощи IPMI (через DCI Manager). После был приобретен некоторый инструментарий для прокладки СКС и мы потихоньку начали строить нечто большее.
Здесь мы видим APC PDU (которые оказались не управляемыми), подключаем:
Вот так, кстати мы установили третий сервер и PDU (справа и слева). Сервер долго служил нам подставкой под монитор и клавиатуру с мышкой.
На имеющемся оборудовании мы организовали некий Cloud сервис при помощи VMmanager Cloud от компании ISP Systems. У нас было три сервера, один из которых был мастером, второй — файловым. Фактическое резервирование у нас было на случай падения одного из серверов (за исключением файлового). Мы понимали что 3 сервера для облака это мало, поэтому доп. оборудование уже было в пути. Благо «доставлять» в облако его можно было без проблем и особых настроек.
При падении одного из серверов (мастера, или второго резервного) — облако спокойно мигрировало туда и обратно без падений. Мы специально тестировали это перед вводом в продакшн. Файловый сервер у нас был организован на неплохих дисках в аппаратном RAID10 (для скорости и отказоустойчивости).
На тот момент у нас было несколько нод в России на арендованном оборудовании, которые мы бережно начали переносить на наш новый Cloud сервис. Очень много негатива было высказано поддержке компании ISP Systems, т.к. адекватной миграции из VMmanager KVM в VMmanager Cloud сделано ими не было, а по итогу нам вообще сказали что этого и не должно быть. Переносили ручками, долго и кропотливо. Разумеется перенесли лишь тех кто согласился на акционное размещение и перенос.
Примерно так мы работали еще около месяца, пока не заполнили оборудованием пол шкафа.
Так мы встречали вторую партию нашего оборудования, опять же HP (не реклама). Просто лучше иметь серверы которые взаимо-заменяемы, чем наоборот.
Исходя из того, что ни у кого из нас нет огромного опыта прокладки СКС (кроме администраторов, которые как обычно не там где нужно) — приходилось учиться всему на лету. Так у нас лежали провода первое время (около дня) когда мы устанавливали серверы.
Примерно так — стало уже после установки всего пришедшего оборудования и прокладки.
По мере роста компании мы все чаще сталкивались с определенными трудностями. Были и проблемы с оборудованием (отсутствие в быстром доступе кабелей SAS-SATA), его подключением, разными тонкостями и с DDoS атаками на нас (прилетали и такие что клали весь ЦОД). Но одна из главных, по нашему мнению — нестабильность ЦОДа в котором мы арендовали шкаф под оборудование. Мы и сами то были, не сильно стабильны, но когда падает и цод в котором ты размещаешься — это совсем плохо.
Исходя из того что ЦОД находился в старом полу-заброшенном здании производственного комплекса — работал он соответственно. И несмотря на то, что его владелец прикладывал все усилия чтобы он работал стабильно (а это истинная правда, Александр действительно молодец и во многом нам помог по началу) — отключали то свет, то интернет. Наверное это нас и спасло. Это стало причиной, которая побудила нас (без имеющихся на то финансов) приступить к поиску помещения для собственного дата-центра и организовать переезд в него менее чем за 14 дней (с учетом подготовки помещения, протяжки оптики и всего прочего) Но об этом, уже в следующей части нашего рассказа. О спешном переезде, поиске помещения и строительстве мини-цода в котором мы сейчас и обитаем.
Как построить ЦОД? Руководство к действию
По большому счету центр обработки данных (ЦОД) является увеличенной копией и логическим продолжением серверной комнаты. Но его принципиальное отличие — комплексное оснащение всем спектром инженерных систем и применение специальных мер по обеспечению работы ИТ-инфраструктуры предприятия в том режиме, который ему необходим. Как показывает практика, на сегодняшний день собственный ЦОД требуется большинству крупных территориально-распределенных компаний, в которых высока зависимость бизнеса от организации ИТ. Например, свои дата-центры строят многопрофильные банки, операторы связи, крупные ритейлеры, транспортные компании и промышленные холдинги и т.д.
Прежде всего нужно просчитать все возможные риски и оценить, нужен ли вообще предприятию ЦОД. Во-первых, необходимо понять, сможет ли компания в ближайшие 5 лет выделить на строительство и эксплуатацию центра порядка 15 млн долл. Типичная ошибка большинства предприятий в том, что они не могут просчитать полную стоимость внедрения ЦОД и, как правило, закладывают в бюджет только строительство. На самом деле на возведение дата-центра приходится примерно 20% от общей стоимости проекта, а 80% бюджета уйдет на дальнейшую эксплуатацию. При проектировании решения стоит задуматься, как скоро потребуется увеличение общей производительности ЦОД и его «пропускной способности» и, самое главное, во сколько обойдется модернизация. Часто, пытаясь сэкономить на начальном этапе, компании ориентируются на дешевые, но плохо масштабируемые решения. Но рано или поздно наступает момент «насыщения» инфраструктуры, и выясняется, что для ее расширения требуются затраты, сопоставимые с первоначальными.
Еще одна типичная ошибка на первоначальном этапе – некорректное проектирование ЦОД. Как показывает практика, успех строительства центра напрямую зависит от проработки технического задания. Уже на этой стадии следует найти профессиональную компанию, которая построит data-центр. Привлечение специализированных предприятий на стадии разработки технического задания целесообразно, так как необходимо предусмотреть сотни параметров, и ошибки в проектировании могут обернуться многомиллионными убытками или неоправданными затратами. «Заниматься возведением центра своими силами не имеет смысла – слишком много здесь узких мест, которые по силам лишь профессионалам», – считает директор Data-Fort IBS Денис Калинин. – Одной теории недостаточно, нужен опыт строительства и эксплуатации. Здесь любой вопрос, вплоть до высоты потолка или глубины второго пола, имеет критическое значение, и ошибка чревата полной неработоспособностью центра в дальнейшем».
При выборе территории под строительство ЦОД необходимо учитывать климатические условия
Кроме того, на начальном этапе при проектировании необходимо грамотно выбрать поставщика оборудования. Как отмечают эксперты, также надо учитывать, что вся техника задержится как минимум на полгода на российской таможне, а некоторое оборудование может не дойти до адреса и вернуться назад к поставщику. Все это обусловлено тем, что к высокотехнологичному оборудованию таможенные органы предъявляют высокие требования. Специалисты компании BCC считают, что где бы ни строился ЦОД – в Европе, России или даже Африке – следует придерживаться единого подхода к построению его архитектуры по принципу «от бизнес-процессов – к железу и ПО», и это главное условие успешного проекта. ВСС представляет грамотную архитектуру комплексного ЦОД в виде пирамиды, где вершиной является уставная бизнес-задача (например, если заказчик оператор связи – то «обслуживание абонентов», если сеть гипермаркетов – то «продажа товаров покупателям» и т.д.), а нижние уровни подчинены ее решению.
Внедрение ЦОД в России имеет свои особенности. Довольно часто его эффективному строительству и функционированию мешает отсутствие нормальных рыночных условий и развитой инфраструктуры. При выборе территории под строительство ЦОД необходимо учитывать климатические условия, возможные проблемы с электричеством, логистикой и транспортной инфраструктурой, с завозом необходимых материалов. При проектировании нужно правильно рассчитать электропотребление, понять, как подвести к зданию электроснабжение. Например, г-н Калинин отметил, что на территории Москвы строить ЦОД бессмысленно, поскольку сегодня действуют запреты на подключение к энергоресурсам столицы. «Если у вас нет готовой электрической емкости, то за подключение ЦОДа к сети потребуется сумма, практически равная стоимости строительства», – сообщил он.
Впрочем, в Подмосковье или других субъектах РФ надо учитывать другие аспекты: для кого строится дата-центр (где находится центральный офис), нужна ли доступность, насколько важно нахождение собственной службы на территории ЦОД. По мнению экспертов IBS, наилучшим местом строительства ЦОД для предприятия с головным офисом в столице является Подмосковье либо города центрального округа, поскольку именно такое расположение обеспечивает надежные каналы связи и хорошие подъездные пути.
Определившись с местом расположения ЦОД, нужно правильно выбрать помещение. Здесь главное – площадь, необходимая для ЦОД, и инфраструктура вокруг здания. Как уже было отмечено, нужно выяснить, какие энергоресурсы будут подключены к ЦОД, площадь необходимо рассчитать с учетом перспектив развития компании. В случае если предприятие только арендует помещение, важно проверить наличие охраны и транспортной инфраструктуры. Само помещение должно располагаться либо в отдельном специальном знании, либо в бизнес-центре. В целях снижения вероятности затопления, пожара и других бедствий для размещения дата-центра нельзя использовать подвальные помещения.
Как я строил свой датацентр — часть первая, подготовительная
Как известно, любой стартап начинается с фразы «Как же вы за***ли, лучше сам сделаю лучше».
В 2007 году положение с датацентрами в Москве, да и во всей России было критическим. Попасть туда простому хостеру можно было только по предварительной записи. Драли с него втридорога, сервера частенько перегревали, электричество периодически отсутствовало, и еще, стоило датацентру начать генерировать 2-3 гигабита полосы, как он тут же воображал себя царем горы, пытался барыжить твоим трафиком, а с несогласными боролся методом пускания моего трафика через узкий зашейпенный канал ***телекома зарубеж.
А общение с ночными дежурными датацентра — это отдельная песня. Чаще всего было проще приехать и самому найти вывалившийся патчкорд, чем полночи пытаться добиться от мало вменяемого, ничего не хотящего юноши. И это хорошо, если дежурный был и попасть в датацентр ночью было возможно. Некоторые датацентры работали с 9 до 5, кроме праздников и выходных дней. Все остальное время там не было НИКОГО. Сервер, упавший в пятницу вечером, пролежит, минимум, до дня понедельника.
Картинка, о том, что творилось внутри типичного датацентра того времени.
Взято с сайта Nag.ru
Мне, к тому времени, это порядком надоело, и, как выход, я решил строить свой датацентр, ориентированный на запросы меня и моих пользователей.
А именно хотелось:
1) Нормального, качественного охлаждения с большим запасом на случай выхода одного из кондиционеров.
2) Беспроблемного электричества и обязательно собственный дизель.
3) Каналы и до местных Tier1 и до пира. Трафик должен стоить нормальных денег.
4) Своей, вышколенной и вменяемой круглосуточной смены на площадке.
Своими мыслями я делился с знакомыми и нашел сочувствующих. Был написан бизнес план. Не спеша были найдены деньги на запуск и клиенты, что бы не работать в минус после запуска.
Был найден и будущий исполнитель строительства датацентра — Группа компаний «Радиус»
Итак прошел весь 2008 год. Зимой количество объектов вдруг резко увеличилось, а арендодатели вдруг стали соглашаться на наши условия, и в январе 2009 года помещение было найдено. Представляло оно из себя не очень приятное зрелище.
Приблизительно вот такое
И с другой стороны
Итак, договор аренды подписан, мы с специалистами группы компаний Радиус засучили рукава и начали делать рабочий проект. Большой такой, талмуд, страниц на 1000. В котором подробно описали как сделать из того, что есть, красоту необыкновенную, нужную нам. К марту проект был готов, и началась стройка.
Как всегда, самое интересное в следующей серии
Как построить модульный ЦОД за три месяца и не наступить на грабли
Этот модульный ЦОД мы построили меньше, чем за три месяца. В первых числах ноября начали монтаж на площадке, а в конце декабря уже сдали его в эксплуатацию.
В общих чертах запрос от заказчика именно таким и был: очень быстро нарастить вычислительные мощности под свой ИТ-проект там, где дополнительного места совсем нет. Решено было построить модульный ЦОД. И сделать это недорого. Спустя год готов рассказать, как это было. Как мы делали полную предварительную сборку и разборку ЦОДа на площадке в Сибири. Как поливали его водой из мойки «Керхер» и разогревали, как духовку.
Заодно поделюсь нашим опытом обхода граблей при строительстве модульных дата-центров. А также расскажу о некоторых граблях, на которые мы все-таки наступили, но в каске.
Суровая правда жизни: начало подготовительных работ
Для тех, кто не особо следит за строительными технологиями ЦОД, краткая справка о модульных решениях:
а) для них не требуется разрешение на капитальное строительство;
б) их можно быстро поставить где угодно, хоть посреди леса, лишь бы было электричество и каналы связи;
в) они как конструктор лего — можно разобрать и перевезти на новое место дислокации. И относительно легко, при необходимости, нарастить.
Что касается именно этого проекта, то основные критичные характеристики для заказчика — обоснование «некапитальности» сооружения и демонстрация возможности неоднократной сборки и разборки. Плюс возможность наращивания ИТ-мощностей в дальнейшем.
Кроме того, в проекте требовалось выполнить монтаж внешних инженерных сетей (КЛ-0,4кВ, сети связи, водоснабжение, водоотведение) и модернизировать существующую электрощитовую. Она находилась в административном здании, от которой выполнялось подключение МЦОД.
Когда начали работу, выяснилось, что на площадке под асфальтом «захоронен» цокольный этаж старого здания, о котором никто, включая заказчика, не знал. В итоге спроектировали бетонную площадку, взяв категорию грунта «Строительный мусор». Разработали котлован, выполнили отсыпку щебнем и песчаной подушкой. Дополнительно залили 300 мм армированного бетона. Таким образом исключили риски перепада плотности грунта под модульным зданием.
Бетонное основание под МЦОД
Внешние сети — как это было
Первые «грабли» состояли в том, что у заказчика не оказалось актуальной версии геоподосновы. Нашелся только архивный файл. Более того, отсканирован он был не в масштабе, и нам было сложно понять привязку коммуникаций и самого модульного ЦОДа. В итоге в наши расчеты все же закралась ошибка в 2,5-3 метра. Из-за нее пришлось сначала убрать одно крытое парковочное место на территории, а потом его восстанавливать.
Работы по устройству внешних коммуникаций шли параллельно с подготовкой бетонного основания. Одновременно заказчик совместно с МОЭСК модернизировал трансформаторную подстанцию РУ-0,4кВ. Это все, конечно, добавило нам головной боли.
Прокладка коммуникаций
Электрощитовую в административном здании мы реконструировали ночью. Требовалось поэтапное отключение линий электропитания всего административного здания, а в нем — потребители I особой категории. Например, в этом же здании находились серверы одной довольно крупной авиакомпании. Естественно, подключали резервный источник питания — мобильный ДГУ — на случай форс-мажорной ситуации. Успели, кстати, за одну ночь все сделать.
Когда закончили работы с коммуникациями, встал вопрос о восстановлении асфальта на парковке. Начали этот вопрос прорабатывать и поняли, что «старый» асфальт положен на все тот же строительный мусор, а мы-то свои траншеи засыпали по правилам! Что произойдет, если положим асфальт? Правильно, в лучшем случае он начнет трескаться на границах разных зон. Посоветовались со специалистами и сделали решение по легкому бетону. Забетонировали тонким слоем площадку, и уже на бетон положили новый асфальт.
Примерно вот так шли работы
Испытание водой и жарой
Одним из ключевых требований заказчика было провести предварительные испытания МЦОД на производстве и показать, что модульное здание соответствует основным требованиям. Пока мы занимались подведением коммуникаций, модульная конструкция уже была в производстве в Новосибирске. Дальше нам нужно было продемонстрировать заказчику возможность сборки и разборки ЦОДа. И вот тут началось самое интересное.
Обычно бывает предсборка модульных ЦОД на производстве, но это не наш случай. Заказчик требовал, чтобы модульное здание было собрано полностью — с фальшполом, с освещением, с общей электрикой и даже с пандусом. План был такой: полностью собрать модульное здание, провести предварительные испытания, разобрать здание, привезти в Москву и затем собрать еще раз.
Для того, чтобы все это провернуть, разместили модуль в огромном крытом цехе на площадке производителя.
Оба снимка сделаны на площадке производителя 3 октября
Приехала целая делегация — и наши инженеры, и представители заказчика. Многочасовые испытания шли два дня. Проводили проверку геометрических параметров модульного здания и помещений, отсутствия возможных «мостиков холода», отклонений высот фальшпола. Контролировали степень освещенности машинного зала на соответствие ТЗ. Еще была проверка на герметичность — поливали ЦОД водой из мойки «Керхер» под давлением.
Но самое необычное испытание — на теплопотери. Для этого мы арендовали тепловые пушки, и с утра в ЦОДе их запустили. Нагрев шел около двух с половиной часов. Температура внутри здания была на 50 градусов выше, чем снаружи. Жара стояла такая, что зайти в ЦОД было тяжело. Представители заказчика с тепловизором проходили вдоль стен и смотрели, нет ли тех самых «мостиков холода» — мест, где теряется тепло. Это было… эпично. Но зато мы точно были уверены, что нагрев и охлаждение ЦОД будет полностью предсказуем в «боевых» условиях.
История с фальшполом
После того, как испытания успешно прошли, примерно за неделю модульное здание было разобрано. Подрядчик погрузил его в фуры, и часть из них сразу выехала в Москву. Выезжали фуры по очереди, чтобы мы могли сразу с колес выгружать и начинать монтаж. Так мы избежали аренды склада. Можно сказать, это грабли, на которые мы не наступили.
Модульная конструкция готовится к отправке из Новосибирска в Москву. 29 октября
Интересная история была с фальшполом. Если кто не в курсе, фальшпол — важная подсистема в ЦОД. Он держит все технологическое оборудование, и от его качества сборки и жесткости во многом зависит надежность ЦОДа.
В проекте у нас были предусмотрены ИБП весом под тонну, да еще и кондиционеры по 900 кг каждый. Подрядчик посчитал нагрузки и попытался убедить нас в том, что, мол, «не извольте сумлеваться, выдержит!»
Но слова «должен выдержать» нас не убедили.
Что мы сделали? Разработали рамы, усиливающие фальшпол под кондиционерами и ИБП. Для бесперебойников это была одна длинная мощная конструкция. Под фальшпол ее опускало человек пять или шесть.
Рамы для ИБП
А под кондиционеры мы сделали раму с ножками. Ножки эти вставали в паз — в существующие металлические фермы основания модульного ЦОДа.
И тут снова «грабли» — из-за спешки ребята-сварщики приварили ноги от другой рамы. Ноги получились короткими, и рама оказалась не на уровне фальшпола. А на следующий день уже все расписано — кондиционеры приезжают, заключен договор на такелажные работы… Звоним нашему инженеру (не просто инженеру, а с большой буквы «И» который). Пара звонков «мужикам» — и за ночь вопрос удалось решить.
Переварили ножки, и раму мы установили. И так как все считали наши ребята, мы спокойны — двукратный запас по прочности там точно есть.
Заказчику все тоже понравилось, кстати.
ДГУ заказывали?
Самое большое зло в этом проекте — сжатые сроки. ЦОД и так сложное сооружение, а тут нужно было уложиться в считанные недели. На сборке работало две смены. Одни люди выходили, другие заходили на объект. И так семь дней в неделю.
Конечно, не обходилось без накладок. Например, лежит материал в доступе у монтажников. Они его берут, но об экономии думать уже некогда. В итоге нашим инженерам-проектировщикам приходилось с ходу определять потребности и докупать расходники. Каждый день и час был на счету.
При сборке кондиционеров был вопрос в качестве пайки медных труб. Когда мы уже подключили кондиционеры и начали испытания, обнаружилось несколько утечек в фреонопроводе. Отдельная история была — найти места этих утечек. Они ведь часто микроскопические.
Или, вот, например, дизель-генераторная установка (ДГУ). Заказчик говорит: у нас установка есть, привезем. Привозят и тут же выясняется, что ДГУ не соответствует их же собственным требованиям! Наигрались мы с ней в итоге: дорабатывали и в части хранения топлива, в части конструкции модуля. Ставили шумопоглощающие маркизы, которые направляют звук в землю, катализатор и глушитель.
Каждый день было перепланирование работ — если что-то успевали быстрее сделать, план сразу переигрывали. Честно говоря, заказчик, да и мы сами, не до конца верили, что успеем за 3 месяца. Но все получилось, успели. Чистая стройка заняла вообще около месяца. Перед самым Новым годом ЦОД запустили.
И напоследок вот, как это было, — три месяца работы в одном видео: