Что такое цоды. Дата-центры Stack Data Network

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

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

Преимущества для бизнеса

Создание многокомпонентных систем, решающих большинство проблем в бизнесе, намного сокращает расходы предприятий. В частности, для компаний с территориально-распределенной инфраструктурой это незаменимое решение, поскольку 1–2 сотрудника, обслуживающих ЦОД , с успехом заменяют множество лиц, работающих в офисах в регионах. Впоследствии многие предприниматели задумались над приобретением центров обработки данных в связи с тем, что потребовалось интегрировать воедино большое количество информации. Риск потерять определенные сведения безвозвратно стал очень велик и обусловил определенные затраты по восстановлению информации. Кроме того, возникли риски по лишению части доходов в связи с простоями по разным причинам. То есть, благодаря своим уникальным особенностям ЦОД обеспечивает эффективную бесперебойную работу любой организации.

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

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

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

• Уменьшение временных затрат на реализацию новых проектов в сфере IT. При работе в дата-центре компании самостоятельно выбирают услуги, которые они хотят получать. Самыми востребованными остаются аренда стойки, юнита, готового сервера, виртуального сервера и резервное копирование данных. Но помимо этого существует ряд других услуг, которыми компании-арендаторы могут при необходимости воспользоваться, что значительно сэкономит время на запуск нового IT-проекта. Например, это аренда приложений, позволяющая избежать масштабных инвестиций на начальном этапе работы. В качестве примера можно привести аренду 1С бухгалтерии – для развертывания готовой системы, пригодной к работе, достаточно заказать и оплатить такую услугу в дата центре. При этом, зачастую, в офисе заказчика не нужно ничего покупать, устанавливать или настраивать, кроме как доступа в Интернет.

• Сокращение затрат на аренду помещения. Сюда можно отнести затраты на электричество, офисные площади, используемые под «серверные», и обслуживание собственных систем охлаждения и устройств бесперебойного питания. Кстати, купленная в офис техника становится основными средствами предприятия, на них начисляется налог на имущество.

• Организация непрерывной работы головного офиса с филиалами компании по всей стране. доступ к рабочей информации независимо от места нахождения сотрудника. Например, руководитель компании может, находясь в отпуске, проверять рабочую почту, связываться со своими сотрудниками через IP-телефонию.

• Возможность создания резервного офиса организации, если по каким-то причинам работа в основном офисе невозможна, а необходимо получить важную информацию, доделать проект

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

Первыми, кто стал использовать в своей работе центры обработки данных, были крупные зарубежные компании. За ними последовали и российские предприниматели. В РФ в 2000-2001 годах появились первые обладатели ЦОД . Пионером выступил Сбербанк России . Именно он является наиболее территориально-распределенной организацией. То есть потребность в создании интеграции многочисленных данных была высока. В дальнейшем собственными ЦОД обзавелись и крупные нефтяные компании.

Типы центров обработки данных

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

• корпоративные дата-центры;
• хостинговые дата-центры, предоставляющие компьютерную инфраструктуру как услугу (IaaS);
• дата-центры, использующие технологию Web 2.0.

Ниже приведены параметры, которые могут значительно отличаться в разных типах дата-центров:

• тип трафика (внутренний, внешний или смешанный);
• использование Layer 2 (L2) и/или Layer 3 (L3) для управлення трафиком в центре или на периферии (Top of Rack);
• технология хранения данных;
• уровень серверной виртуализации;
• общий размер центра обработки данных (по количеству серверов).

Создание и модернизация ЦОД

Компоненты ЦОД

Традиционный ЦОД

Обязательные компоненты, входящие в состав ЦОД , можно разделить на три основные группы:

1. Технические компоненты . Они создают условия для эффективной работы центра. К таковым относятся:

• серверный комплекс, включает серверы информационных ресурсов, приложений, представления информации, а также служебные серверы
• система хранения данных и резервного копирования – ядро ЦОД. Она состоит из консолидирующих дисковых массивов, сети хранения данных, системы резервного копирования и аварийного восстановления данных
• сетевая инфраструктура обеспечивает взаимодействие между серверами, объединяет логические уровни и организует каналы связи. Она включает магистрали для связи с операторами общего доступа, телекоммуникации, обеспечивающие связь пользователей с ЦОД
• инженерная система эксплуатации ЦОД поддерживает условия для нормального функционирования центра. В ее состав входят подсистемы энергообеспечения, климатконтроля, пожарной сигнализации и пожаротушения, передачи данных, а также автоматизированные системы диспетчеризации, управления информационными ресурсами
• система безопасности предотвращает несанкционированное вторжение в зоны конфиденциальной информации. Она состоит из средств защиты, системы оповещения и системы контроля доступа

2. Программное обеспечение . Это фактически сервисы инфраструктуры ЦОД и ПО для корректной работы бизнес-процессов , необходимых для конкретной организации. К компонентам инфраструктуры относятся:

• операционные системы серверов;
• программное обеспечение баз данных;
• операционные системы рабочих станций;
• средства кластеризации ;
• средства резервного копирования;
• программы устройств хранения данных;
• средства администрирования серверов и рабочих станций;
• средства инвентаризации;
• офисное программное обеспечение;
• электронная почта;
• Интернет -браузеры.

К программам, отвечающим за функционирование бизнес процессов, относятся:

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

3. Организационная среда решает вопросы, связанные с предоставлением IT-услуг. Она должна соответствовать требованиям по оказанию IT-услуг, таким как ISO/IEC 20000. Здесь представлены:

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

Программный ЦОД

В программном ЦОДе мы все окружение реализуем в виде программных модулей в виртуальных машинах – virtual appliance. Идея состоит в том, что физически используются только серверы и коммутаторы . Все остальное реализуется в виде виртуальных машин – virtual appliance.

В мире сервис-провайдеров эта технология известна и даже стандартизована под названием NFV – Network Function Virtualization – виртуализация сетевых функций. Только там это используется для предоставления сервисов и соответственно очень много внимания уделяется средствам оркестрации и управления, интеграции с OSS системами, что позволяет автоматизировать процесс создания услуг для каждого из абонентов. В корпоративном ЦОД так часто состав услуг менять не надо, уровень автоматизации может быть существенно ниже, но перенос всех сетевых функций в виртуальные машины все равно дает существенные преимущества.

Для начала определимся с тем, что идея строить ЦОД не только посетила клиента, но и закрепилась, а ИТ-директор, которому требуется обеспечить надежное функционирование бизнес-приложений, понимает, что время «Ч» пришло. Бизнес понимает, что риски потери прибыли очень большие, требуется надежное функционирование ИТ и нужно инвестировать средства в нормальный ЦОД. Поэтому далее поговорим о самом процессе создания ЦОД не с тех-нической точки зрения, а организационной.

Итак, с чего начать? С идеи. А по--чему бы и нет? Интегратор здесь дол-жен выполнить роль психолога: приехать к клиенту и поговорить о том, что он в итоге хочет получить от ЦОДа. Здесь важны две вещи: не формализовать процесс и не зарыться в детали. Формализация процесса обычно сводится к отправке клиенту кучки опросников и таблиц. Безусловно, это нужно делать, но только не на первой или второй встрече. Поэтому лучше разбивать большой опросник на несколько небольших и передавать их профильным специалистам компании-клиента. Емкие опросные листы с множеством технических подробностей обычно просто не заполняются, и тут виной всему человеческий фактор. Увы, факты — вещь упрямая, и по собственному опыту скажу, что универсальный опросник, включающий в себя все-все-все, заполняют не более 1-3 % клиентов. Обычно это выглядит так: высылаете, неделя-две потерянного времени, приезжаете и начинаете беседовать. Живое общение позволяет значительно сэкономить время, которого обычно и так нет: почему-то решение строить ЦОД принимается «на вчера», и клиент обычно год думает, как построить ЦОД за два месяца:).

Предварительная работа с клиентом

Установочная встреча состоялась, и дальше — работа пресейл-специа-листов и ключевых специалистов клиента. Важно, чтобы пресейл умел говорить на двух языках — языке финансистов и языке технического персонала. Пресейл — это своеобразный переводчик, способный понять потребности клиента и оценить, на какую сумму потянет проект и будет ли это выгодно клиенту. Более того, такой специалист решает дилемму, помогая рабочей группе клиента защитить бюджет просчитанного решения перед финансовым директором. Расчет таких показателей, как окупаемость инвестиций (ROI), общая стоимость владения (TCO), внутренняя норма доходности (IRR), период окупаемости (PP), позволит обосновать топ-менеджерам, почемунужен именно 1 миллион и недостаточно 200 тысяч, «чтобы айтишники успокоились и наигрались», а также учесть особенности финансирования и этапность инвестирования. В идеале здесь клиенту нужно представить хотя бы укрупненный инвестиционный план для понимания конечности затрат ЦОД и выбора модели его использования: будет ли это свой ЦОД, арендуемый коммерческий или «облачный» сервис. Обычно для корпоративного клиента это будет некий гибрид, в котором будут все три типа. В этом случае топ-менеджер понимает смысл всей затеи, финансовый директор — конечность затрат, а ИТ-директор — насколько ЦОД будет соответствовать потребностям бизнеса.

Еще одна важная деталь на данном этапе — не следует слишком увлекаться резервированием и фактором надежности. Часто бывает так: строительный департамент выбирает дублирование источников электроснабжения и кондициониро-ва-ния. ИТ-департамент дублирует ли-нии свя-зи и ИТ-оборудование, специалис-ты по бизнес-приложениям делают синхронную репликацию и «горячее дублирование» работающих узлов… В итоге цена зашкаливает, хотя каждый департамент в отдельности поступил правильно и максимально проработал свою зону ответственности. Поэтому при сравнении вариантов бюджетирования и описании концепции нужно опираться именно на сравнение вариантов под ключ. К тому же не стоит забывать, что при прочих равных стоимостях две площадки Tier III всег-да бу--дут более надежными, чем Tier IV, ведь в этом случае уменьшает-ся стои-мость внешних рисков.

Выбор площадки

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

Особое внимание стоит уделить следующим вопросам:

1. Подвод коммуникаций.

Здесь стоит особо обратить внимание не просто на возможности подвода коммуникаций, а стоимос-ти проекта под ключ. Очень часто тех-ническая возможность есть, а вот стоимостная… То слаботочные ка-нализации надо копать или арендовать, то трансформаторную подстанцию (ТП) надо свою ставить и завязываться с 10 кВ. Поэтому не стоит соблазняться на разговоры и обещания, пока нет валидных технических условий на подключение. Они хотя бы позволят гарантировать, что в рамках временного промежутка (обычно одного года) затраты не вырастут. Отдельно желательно проинспектировать независимость энерговводов. Как показывает практика, велика вероятность во время этой процедуры получить неприятный сюрприз: узнать, например, что два ввода тянутся от одной подстанции. По каналам связи: учитывайте, что их должно быть несколько и тянуть их желательно разными трассами. Темное волокно идеально, но чрезвычайно дорого. Коммутируемые линии связи, которые проходят между разными провайдерами, — дешево, но сердито: в случае аварии время даунтайма может быть непрогнозируемо. Поэтому золотая середина — канал связи от одного провайдера, который владеет всей сетью из точки А в точку Б (особенно это касается связи между основным и резервным ЦОДами).

2. Расположение ЦОД.

Есть несколько важных моментов:

а) План заноса крупногабаритного оборудования. Важно понимать, что оборудование надо не просто занес-ти, и оно, естественно, должно пройти в дверные проемы, но и развернуть его, погрузить и снять с тележки.

б) Наличие достаточной нагрузки на перекрытие и конструкции стен. Стоит ли говорить, что оборудование на-до не просто занести и пос-та--вить — его еще нужно и довезти. Поэтому обращаем внимание на то, какая наг-рузочная способность перекрытий по путям транспортировки (прова-лен-ный фальшпол, раздробленная плит-ка и т. д. совсем не добавят удобства при эксплуатации, когда ЦОД уже будет построен). Наконец, тре-буется архитектурная экспертиза зда-ния «на сегодня». Часто она есть, но 15-летней давности. Конечно, мож-но экстраполировать и гадать на ко-фейной гуще, но стои-мость рисков зна-чительно выше, чем стоимость такой экспертизы. Что касается стен — здесь важно, сколько на них можно наг-рузить, ведь кабельные эстака-ды, на-весные щиты при проектировании для экономии площади проще повесить на стену.

в) Высота помещения. Не стоит забывать, что в ЦОД надо не просто поставить шкафы, а сделать еще и многоэтажные кабельные трассы элект-рики и слаботочки, поэтому высота лишней не бывает. Особенно если планируются шкафные кондиционеры с выдувом под фальшпол — решение простое, недорогое и при правильном расчете позволяющее отвести до 15 кВт со шкафа (в теории можно и больше, но жалко объема помещения). Так на какую же величину стоит ориентироваться? Эмпирика показала: 4,5 метра. Но уж точно не меньше трех метров.

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

д) Организация подъезда к ЦОДу. Есть ли возможность прямого подъезда автопоезда к воротам ЦОД? Возможно ли организовать выгрузку напрямую из прицепа в здание?

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

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

Взаимодействие команд интегратора и клиента

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

Основные моменты, на которых стоит заострить внимание:

1. Найти нужных людей, определить реальные роли в проекте. Как найти нужного человека? Ответ прост. Попробуйте его мысленно убрать — что-то изменится? Если нет — этот человек не нужен. Проект ЦОД не требует большой постоянной команды, поэтому лучше не включать в основной состав более 5-7 человек с каждой стороны.

2. Человек противится переменам, пока не почувствует себя в безопасности. Поэтому не стоит удивляться, что, как правило, команда людей со стороны клиента более консервативно настроена. Это нормально, ибо их задача — не просто построить ЦОД, но еще и жить с ним, потому любые революционные решения встречаются настороженно: продукт сырой, статистики отказов нет, каков он в эксплуатации — непонятно... Это не значит, что новые продукты не стоит внедрять — просто их внедрение потребует более детальной проработки, в том числе с клиентом.

3. Доступные каналы для доставки плохих известий. Спорный момент, но он необходим, и особенно в команде интегратора. Часто менеджер проекта узнает об этих новостях, когда ничего изменить нельзя, а случившееся можно принять как факт, хотя многие и знали об этом, но скрывали, надеясь на «авось решится».

4. Формальные программы, направленные на улучшение существую-щего процесса (все возможные серти-фи-кации специалистов, оценка пер-со-нала), будут дорого стоить команде и во временном, и в денежном отношении. И даже если улучшение и прои-зойдет, оно вряд ли покроет затраты. Проект ЦОД — достаточно сложный в организационном плане из-за большого количества вех и ключевых точек стыковки этих самых вех. Поэтому обу-чение, разработка конфигураторов, шаблонов и т. д. — это та работа, которая может загрузить ключевых специалистов команды в самый неподходящий момент и затянуть работы, стоящие на критичном пути.

5. Чем сложнее проект, тем больше времени уходит на проектирование и меньше — на пусконаладку. К сожалению, проектирование на постсоветском пространстве является контрастным: либо это старая советская школа, когда проектирование выполняется фундаментально, неспешно и без привязки к финансовым затратам, либо это полный антипод советской школы — коммерческий подход, где во главу угла ставится составление спецификации, быстрая закупка с последующим монтажом на объекте («как-то сами ребята разберутся потом»). С учетом отечественных реалий — клиент всегда спешит, и ЦОД ему нужен «еще вчера»: на стадии проектирования всегда хотят ужать сроки. Можно долго говорить о неправильности такого подхода, но разумный максимум, как ускорить этот процесс, — это разработка концепции и эскизного проекта при двухстадийном проектировании (или утверждаемой части при одностадийном), согласование с заказчиком и закупка крупноузлового оборудования, имеющего длительный срок поставки. Материалы и более мелкие узлы можно детализировать в рабочих чертежах, которые и пойдут в монтаж. При этом срок проектирования тот же, но поставка материа-лов будет осуществлена раньше, соответственно, срок реализации ЦОД значительно уменьшится.

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

7. Спецификацию, в которой нет спис-ка входящей и исходящей информации, даже не следует принимать во внимание. Поэтому работать по чьей-то спецификации или спе-цификации, посчитанной «одной известной компанией», не стоит, если нет понимания, какое техническое задание ставилось. Общий совет для руководителя проекта со стороны клиента: прежде чем заказывать проект у сторонней компании и после этого проводить тендер на внедрение, задайте вопрос, кто выступит аудитором качества такого проекта? Не будут ли это зря потраченные время и деньги? Общий совет для руководителя проекта со стороны интегратора: не утешайте себя тем, что вы просто поставите цены в специ-фикации чьего-то проекта, и весь риск ляжет на плечи клиента. Это не так, ведь, скорее всего, в договоре клиент захочет получить не расчет монтажа материалов, а работающую сис-тему, которая обладала бы рядом параметров. А значит, отвечать все равно будет интегратор, выполняющий внедрение.

8. Если в проекте участвует большая команда, это снижает эффективность самой ответственной части работы — определения концепции ЦОД (ведь всем надо побыстрее дать работу), что приводит к потере независимос-ти внутри команды, увеличению числа собраний и совещаний. Поэтому придерживайтесь следующего принципа: сначала маленькая команда, после концепции — подключение новых игроков. Очень часто доводилось наблюдать, когда на первое же совещание приезжает 30-40 человек, которые пытаются обсудить все и сразу, разбиваются на группы, что-то обсуждают и… уезжают. После этого во время формирования общего протокола возникает конфронтация — и все опять собираются. И так до бесконечности. Определите ключевых сотрудников (со стороны клиента это обычно ИТ-ди-ректор, со стороны интегратора — Руководитель проекта), а остальных подключайте по мере необходимости. Эмпирически оптимальная группа, с которой еще можно решать вопросы, — это группа до 10 человек.

9. У проекта должно быть два сро-ка — запланированный и желае-мый. И они не должны совпадать. Это должен понимать и руководитель проек-та ЦОД у клиента, и представитель интегратора. Как правило, они рапор-туют наверх о сроке окончания проекта, а так как ЦОД — это все-та--ки основа для разворачивания бизнес-сервисов, может произойти такое, что совершенно независимые проекты будут связаны, при этом ни одна из команд проектов не будет об этом знать. К примеру, будет заказано оборудование и сформирована заяв-ка на командировку иностран-ных специалистов для его пусконаладки. В то же время ЦОД еще не запущен, оборудование не включено в рабо-ту, а специалисты уже прибыли для пусконаладки — компания несетубытки, и в результате — срыв сроков…

Проектирование

Прежде чем начать проектирование, нужно определиться с техническим заданием (ТЗ) и согласовать его с клиентом. Хоть это и должен делать клиент, выскажу свое скромное мнение: это все-таки должен делать интегратор совместно с клиентом. Почему? Да потому что именно интегратор более компетентен: у него больший опыт и подчас больше понимания, что нужно клиенту. В ТЗ обязательно фиксировать не общие фразы (наподобие «система кондиционирования долж-на поддерживать температуру в сервер-ной в пределах рекомендованной произ-водителем ИТ-оборудования»), а конкретику, нап-ример: обеспечить температуру воздуха на воздухозаборниках ИТ-оборудования в шкафу в пределах +20...24 °С круглосуточ-но в любое время года.

Важна фиксация в ТЗ двух ключе-вых величин: количество этапов и мощность ИТ-оборудования на пер-вом этапе. Неоднократно доводи-лось наблюдать, как при расчетном PUE в 1,4-1,7 на первом этапе оно равнялось двум-трем именно по той причине, что первая стадия ИТ-оборудования составляла 1/10 от той, что была указана в ТЗ. Если есть спецификация ИТ-оборудования и понимание этапности его закупки, которое планирует-ся устанавливать, не поленитесь и расставьте его в стойки. Тогда будет понимание и того, какая мощность на стойку требуется реально, сколько портов структурированной кабельной системы (СКС) и каких именно понадобится, какие разъемы питания потребуются на блоках распределения питания в шкафах.

Далее прорабатывается общая кон-цепция: компоновка помещений, размещение крупноузлового оборудования, проходы, зоны обслуживания оборудования. Часто встает та-кая за-дача: есть мощность 1000 кВт от транс-форматорной подстанции (ТП) — как ее разделить? Делим просто: обычно PUE составляет 1,6-1,8. Соответственно, задаем PUE 1,6 на начальном этапе для ИТ-оборудования, оставляем мощность 625 кВт, для остального оборудования (а это в основ-ном кондиционирование) — 375 кВт. Далее рассчитываем зоны ИТ-шкафов. Не за-бываем, что крайне желательно физически разделить помещение ввода, зоны серверов, стоечных Hi-End (так как часто им нужна специфическая организация охлаждения, которая может отличаться от типового в серверной) и коммутационной зоны (мощность которой обычно значительно ниже, чем серверной зоны).

После того, как у нас появилось по-нимание концепции системы кондиционирования, подключаем электриков, выдав им основную ведомость токоприемников для ИТ, систем вентиляции и кондиционирования. Теперь можно прорисовывать однолинейную схему и проводить расчет дизель-генераторной электростанции.

Если в проекте кондиционирования предусматривается фальшпол, то его высота рассчитывается, а не выбирается произвольно. Плитки фальшпола играют роль координатной сетки, поэтому привязка всех шкафов к сетке обязательна — это необходимо, чтобы обеспечить свободный подъем плиток в проходах между оборудованием и доступ в подфальшпольное пространство. Тут же стоит учесть нормальную ширину прохода не только между шкафами, щитами, кондиционерами и другим оборудованием, но и соблюсти требования, прописанные в нормативных документах, между открытыми дверями и стеной или другим шкафом, обеспечив тем самым технику безопасности и удобный монтаж/демонтаж оборудования.

Системы контроля доступа, сигнализации и пожаротушения рассчитываются, когда есть понимание требуемого количества помещений. Для системы автоматического пожаротушения важны также наличие фальшпола, изоляции коридоров и фальшпотолков. Когда появляется расстановка рядов шкафов и проходов между ними, можно начинать проектирование системы видеонаблюдения. После этого, с учетом класса зрительных работ и требований предыдущей системы, проектируется освещение.

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

Внедрение

Процесс внедрения может сильно отличаться в зависимости от архитектуры, но в целом последовательность процесса примерно следующая:

1. Работа под реконструкции помещений, перенос/возведение стен, выполнение проемов для прохода коммуникаций, расширение дверных проемов, выполнение наружных работ по прокладке кабельных каналов, заливка фундамента для дизель-генераторов и баков топливохранилищ, прокладка топливопроводов, прокладка наружных коммуникаций к зданию ЦОД, выполнения заземления и молниезащиты. При необходимости — выполнение электромагнитного экранирования сер-верного помещения.

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

3. Установка плит фальшпола, установка внутренних блоков кондиционирования, установка шкафов, установка щитов и ИБП в щитовой, установка ДГУ.

4. Монтаж СКС, монтаж АГП, СКД, видеонаблюдения, освещения, оборудования мониторинга и автоматики.

5. Проведение измерений, испытаний, стартап оборудования инженерных сис-тем, пусконаладка.

Сдача в эксплуатацию и сервисное обслуживание

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

Что касается сервисного обслуживания, то здесь могут быть варианты. Это может быть самостоятельное обслуживание ЦОД персоналом клиен-та. Минусы очевидны: необходимость держать в штате специалистов требуемой квалификации. Второй ва-риант — обслуживание каждой системы узкопрофильной компанией. В этом случае клиенту достаточно будет следить только за регламентом об-с-луживания, но придется самостоя-тельно решать стыковые вопросы по сер-вису, если таковые возникают. К примеру, если возникла проблема с задействованием нескольких систем, потребуется выступить посредником в решении вопроса между несколькими организациями, что тоже потребует наличия некоего опыта у человека, который будет курировать сервисное обслуживание, или же привлечения внешнего аудитора. Третий вариант самый простой для клиента, но он может оказаться дороже: аутсорсинг сервисной поддержки интегратором, имеющим экспертизу. В этом случае все риски по стыковым вопросам ложатся на плечи одной организации.

Вопрос о необходимости SLA не так однозначен: если ЦОД спроектирован правильно и системы имеют резерв, то SLA — это затраты, которые далеко не всегда оправдаются. Единственный вариант, который может их оправдать, — полный аутсорсинг обслуживания ЦОД, когда клиент вообще не задействует своих специалистов для отслеживания жизнеспособности ЦОД.

В заключение можно сказать следующее: ЦОД — это отличный пример комплексного проекта, который требуется реализовать в кратчайшие сроки без права на ошибки и переделки. Потратьте больше времени на проектирование и изучение рисков, и оно сторицей окупится во время сдачи и пусконаладки, а также сэкономит немало нервов и денег во время реализации. Помните, что ЦОД — это не просто затраты. Это способ сэкономить деньги на потерях бизнеса, это увеличение капитализации компании. Разумный подход к формированию бюджета при проектировании ЦОД и его защите позволит вернуть эти деньги через определенный промежуток вре-мени. При правильном подходе и по-нимании «дорожной карты» проек-та построения ЦОД сделать это просто.

Константин Коваленко

Построение ЦОД - важная задача не только для преуспевающего руководителя предприятия, но и для любого начинающего бизнесмена с «наполеоновскими» планами. Ведь в современном мире только организация ЦОД способна обеспечить безотказную работу информационной инфраструктуры предприятия, непрерывную доступность, эффективность и безопасность больших массивов электронных данных и интегрированных систем, грамотное внедрение автоматизированных систем управления, таких как CRM и ERP, увеличение мощности it-инфраструктуры и т. д.

Основные этапы организации ЦОД и их содержание

Многие потенциальные Заказчики убеждены, что построение ЦОД - разовая услуга, которая заключается в физическом монтаже, подключении и настройки оборудования. Однако по-настоящему грамотный подход к организации ЦОД предполагает непрерывный и долгосрочный процесс, который реализуется в течение всего срока жизни дата-центра и условно разделяется на пять основных этапов:

• разработка концепции ЦОД
• создание проекта ЦОД
• реализация (внедрение) дата-центра
• техническое обслуживание системы
• модернизация ЦОД

Разработка концепции организации центра обработки данных (ЦОД)

Экономическая эффективность и общий успех проекта ЦОД зависит от степени детализации его первоначальной проработки. Вот почему основной задачей первого этапа является определение места ЦОД в структуре бизнес-процессов предприятия-Заказчика. Таким образом, в ходе совместной работы подрядчика и Заказчика формируется общее представление о будущем ЦОД: выявляются основные цели и задачи системы, ее структура, состав элементов и т. д. Также при разработке системы необходимо учитывать региональные особенности объекта, планируемый бюджет, выбор площадки для ЦОД. Собранные данные ложатся в основу технического задания на проектирование вычислительного центра и подсистем его жизнеобеспечения.

Создание проекта ЦОД

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

Реализация (внедрение) дата-центра

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

Техническое обслуживание системы

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

Модернизация ЦОД

И, наконец, в условиях стремительного развития it-технологий, любой даже самой совершенной вычислительной системе рано или поздно потребуется модернизация. Под данной процедурой понимаются технические и структурные изменения ЦОД, направленные на повышение его производительности, надежности, безопасности и эффективности. Тем самым, благодаря грамотно проведенной модернизации система будет наиболее оптимально соответствовать растущим it-потребностям предприятия.

Для компании «Флайлинк» организация ЦОД является одним из приоритетных направлений услуг. Наши решения основываются на многолетнем опыте работы, передовых технологиях и надежном оборудовании от ведущих отечественных и зарубежных производителей.

Давно построенные центры обработки данных (ЦОД) перестают соответствовать требованиям организаций, владеющих ими. Это главный вывод, который следует из результатов нашего опроса. Примерно половина респондентов заявили, что обязательно или предположительно будут модернизировать системы электропитания и охлаждения оборудования своих ЦОДов в ближайшие 12 месяцев. Перед большинством организаций стоит головоломная задача - как проводить необходимую модернизацию? С одной стороны, инфраструктура старого ЦОДа уже не годится для нормальной работы современных серверов, систем хранения данных и сетевого оборудования, которые потребляют все больше электроэнергии в расчете на единицу площади ЦОДа, а с другой - строительство нового ЦОДа может оказаться очень уж дорогостоящим делом.

У большинства организаций просто нет выбора. Дело в том, что им приходится сохранять и обрабатывать (новыми и более сложными способами) постоянно растущие объемы данных, и нет никаких признаков ослабления этой тенденции. И какими бы полезными ни были консолидация серверов и повышение эффективности управления хранением данных, рано или поздно вам все равно придется реконструировать свой старый ЦОД или строить новый.

Наибольшую озабоченность у ИТ-специалистов продолжают вызывать проблемы с электропитанием и охлаждением оборудования ЦОДа. Но в ответах на наш вопрос, испытывают ли организации дефицит свободного места в своем ЦОДе, были выявлены два интересных факта. Первый - почти половина опрошенных сказали, что в их ЦОДе вполне достаточно места для дальнейшего развития его ИТ-инфраструктуры. Такого ответа можно было ожидать, ведь рабочие характеристики серверов и систем хранения данных непрерывно улучшаются при сохранении или уменьшении их габаритных размеров. В результате для повышения эффективности работы ЦОДа отнюдь не всегда нужна дополнительная площадь. Второй факт показался нам довольно неожиданным: почти четверть респондентов заявили, что для организации своих ЦОДов они используют обычные, не предназначенные для этого помещения.

Мы не стали глубоко вникать, что является причиной этого, но можно предположить, что ответившие так респонденты работают в небольших компаниях или в удаленных филиалах крупных организаций. В любом случае решения типа «ЦОД в коробке» - системы размером с холодильник, снабженные необходимыми для эксплуатации примерно 30 серверов (или других сетевых устройств) высотой 1U средствами охлаждения и источниками бесперебойного питания (ИБП), должны пользоваться большим спросом.

Результаты опроса указывают на движущие силы консолидации ЦОДов. Чтобы решить ряд проблем, включая обеспечение соответствия законодательным требованиям по информационной безопасности и повышение надежности хранения данных, нужно совершенствовать системное управление, а для этого желательно переместить серверы подразделений компании и ее удаленных филиалов в ЦОД.

Что же на самом деле лучше?

Очевидно, что предприятиям нужны улучшенные ЦОДы. Но что же значит «улучшенные»? Должны ли, например, серверы быть специализированными или как можно более универсальными? Следует ли покупать блейд-системы или это всего лишь еще один способ «привязать» заказчика к конкретному производителю? Поможет ли питание оборудования постоянным током (DC) сократить расходы на электроэнергию или от такого типа питания будет больше проблем, чем пользы? Нужны ли фальшполы, или они уже устарели? Число вопросов кажется бесконечным, но совершенно ясно, что строить объекты (для организации ЦОДов) того же типа, какие строились всего лет пять назад, - провальная затея. Возможно, самой большой проблемой для организаций, планирующих строительство ЦОДа, является высокая стоимость последнего.

Раньше большинство систем электропитания для оборудования ЦОДов рассчитывались на удельную мощность 50 Вт/кв. фут (1 кв. фут = 0,0929 кв. м), но сейчас многие аналитики рекомендуют иметь систему удельной мощностью 500 Вт/кв. фут. Десятикратное увеличение удельной мощности систем электропитания (включая ИБП и электрогенераторы), а также необходимость иметь соответствующие системы охлаждения, делают затраты на реализацию этих систем самой большой статьей расходов при создании ЦОДов. Если вы хотите построить ЦОД уровня IV с надежностью работы «пять девяток» (в соответствии с определением организации Uptime Institute), то расходы на приобретение и монтаж его систем электропитания и охлаждения могут аж в 50 раз превысить затраты на строительство собственно здания ЦОДа (165 млн долл. против 3,3 млн в случае строительства ЦОДа площадью 15 тыс кв. футов). А ежегодная плата за электроэнергию при использовании ЦОДа вышеуказанной площади, как говорится «на полную катушку», составляет 13 млн долл. (в Калифорнии), что почти в пять раз превышает стоимость строительства его здания.

Учитывая столь значительные расходы на реализацию инженерной инфраструктуры ЦОДа и затраты на оплату электроэнергии, имеет смысл критически оценить все детали конструктивного решения его помещения. Одним из спорных моментов при проектировании ЦОДов является наличие фальшпола, поскольку последний становится бесполезным при высокоплотном размещении оборудования в монтажных стойках. Всего шесть лет назад среднее энергопотребление стойки с оборудованием было около 3 кВт. Сегодня этот показатель составляет почти 7 кВт, а при заполнении стойки блейд-серверами ее энергопотребление может возрасти до 30 кВт и больше. Ни одна из существующих систем охлаждения через фальшпол не рассчитана на такую концентрацию тепловой нагрузки. Но не только проблемы с охлаждением заставляют усомниться в необходимости фальшпола.

С увеличением энергопотребления стоек с оборудованием растет и их масса. Полностью заполненная аппаратурой стойка может весить от четверти тонны до одной тонны и даже больше. Чтобы фальшпол выдерживал столь тяжелые стойки, его нужно укреплять дополнительными подпорками. Вместо того чтобы полагаться на систему охлаждения через фальшпол, стоит рассмотреть варианты использования средств охлаждения, работающих на уровне стойки или ряда стоек, в качестве дополнения к этой системе или ее полной замены. Данные средства хороши тем, что они модульные и подают хладагент именно туда, куда нужно, это и делает их более эффективными.

DC или AC?

Проанализировав лучшие подходы к построению ЦОДов, вы несомненно получите большую пользу. Но один подход мы не советовали бы вам брать на вооружение - это использование систем электропитания DC вместо систем электропитания переменного тока (AC), которые в настоящее время преобладают в ЦОДах.

Системы электропитания DC нужны организациям, сетевая инфраструктура которых должна соответствовать требованиям NEBS (Network-Equipment Building System). Как правило, это телекоммуникационные операторы, использующие такие системы уже много лет главным образом по причине их высокой надежности и простоты подключения альтернативных источников питания (батарей и генераторов).

Предприятия других отраслей тоже проявляют интерес к DC-электропитанию, поэтому любой крупный производитель серверов выпускает по меньшей мере несколько моделей, питаемых от DC-систем. Одним из производителей, специализирующихся на выпуске таких серверов, является компания Rackable Systems.

Существует ряд факторов, препятствующих использованию DC-электропитания в ЦОДах. Во-первых, выбор ИТ-продуктов с таким типом электропитания сравнительно невелик. Во-вторых, построение DC-системы электропитания в масштабе ЦОДа требует специальных знаний и навыков - достаточно не затянуть хотя бы один болт на шине DC и она может расплавиться. В-третьих, вам придется разместить инверторы вне помещения ЦОДа, чтобы выделяемое ими тепло не мешало охлаждать установленное там оборудование.

В-четвертых, DC-системы электропитания обычно стоят дороже AC-систем (впрочем, имея более высокий КПД, DC-системы потребляют меньше электроэнергии, и вы можете сэкономить на снижении совокупной стоимости владения ими).

И наконец, в-пятых, если серверы, коммутаторы, маршрутизаторы и системы хранения данных с DC-электропитанием на рынке имеются, то DC-кондиционеров для ЦОДов не существует. Это означает, что вам придется реализовывать в ЦОДе две системы электропитания - DC и AC, но очевидно, что гораздо лучше иметь дело с системой только одного типа. По указанным выше причинам DC-электропитание в ЦОДах, ориентированных на разнообразные ИТ-приложения, не стало популярным.

Компания «Строй-ТК» проведет проектирование и монтаж ЦОД для Вашего бизнеса.

Ознакомиться с нашими услугами по проектированию, строительству, эксплуатации ЦОД Вы можете .