ЦОД - от проекта до эксплуатации. Обоснование создания и составление ТЗ. Когда ЦОД (центр обработки данных) становится необходимостью Функции цод

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

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

Услуги ЦОД

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

Стандартные сервисы центров обработки данных:

Дополнительные сервисы центров обработки данных:

• Бекап
• Облачные решения
• Администрируемый сервер
• Удаленный рабочий стол

Технологии, применяемые в ЦОДах

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

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

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

Отличия центров обработки данных

Стандарт TIA-942

По этому стандарту все ДЦ получают определенный уровень - от tier1 до tier4.

Дата-центр TEL формально соответствует стандарту tier2+.

Формат

По этому критерию выделяют:

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

ЦОД TEL Hosting находится в собственности телекоммуникационной компании TEL и относится к сооружениям первого типа.

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

Область применения документа и перечень рассматриваемых вопросов

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

В документе рассматриваются:

• Проблемы, появляющиеся на этапах проектирования, строительства и эксплуатации ЦОД, а так же возможные решения этих проблем
• Приводятся рекомендации по использованию современных стандартов, а так же даётся краткая их характеристика
• Приводятся основные ошибки при проектировании, и проблемы, появляющиеся при эксплуатации, показываются их последствия, а так же возможные пути устранения ошибок и решения проблем
• Отдельно приводятся правила создания успешных IT-проектов
• Раскрываются наиболее важные требования к основным элементам ЦОД, и по возможности, объясняется причина этих требований и последствия их несоблюдения
• Перечисляются основные тенденции в создании ЦОД и некоторые статистические данные зарубежных и российских ЦОД

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

Предварительно я попытаюсь уточнить круг специалистов, для которых документ будет ориентирован. Это будут специалисты организаций не имеющие ЦОД, но желающие его построить, специалисты принявшие решение построить ЦОД, но не знающие, на что обратить внимание при написание технического задания (Т)З и как выбрать партнёра, специалисты, построившие ЦОД, но пытающихся при эго эксплуатации обеспечить заявленные характеристики и снизить затраты. А также вероятно документ будет интересен поставщикам оборудования и разработчикам ЦОД, хотя бы в плане понимания проблем их клиентов. Хотя документ и будет рассматривать большинство вопросов возникающих при обосновании выбора ЦОД, его проектировании, построении и эксплуатации, но в документе не будет указаний на выбор того или иного оборудования, и даже на обязательное использование тех или иных технологий. Дело в том, что новая техника, решения и технологии появляются каждый год, часто, по сути, отличаясь внесением некоторых несущественных изменений, или реализацией давно известных решений, но на новом техническом уровне. Помните — «Знание нескольких принципов, освобождает нас от знания множества частностей ». Исходя из этого, я и постараюсь в первую очередь, рассказать о принципах проектирования и эксплуатации сложных вычислительных систем, которые, как нельзя лучше подходит для ЦОД.

Для того, что бы обсуждать проблемы построения и эксплуатации ЦОД надо определиться с некоторыми терминами и понять что же такое ЦОД. Поэтому вначале я попытаюсь определиться с самим термином «ЦОД».

Определение термина «ЦОД»

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

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

Если обратиться к Википедии то ЦОД или центр хранения и обработки данных (ЦОД /ЦХОД ) - это специализированное здание для размещения (хостинга) серверного и коммуникационного оборудования и подключения абонентов к каналам сети Интернет. Другое название ЦОД — Дата-центр (от англ. data center ).

Замечание : Если в документе приводится термин «Дата-центр », то это означается, что цитируется, или пересказывается документ, где используется именно такой термин, а не термин «ЦОД ».

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

Во всяком случае, в определении ЦОД не стоит подчёркивать наличие хостинга и сети Интернет, т.к. они действительно могут быть, но их отсутствие не является критичным для ЦОД. В том виде, как приводится уточнённая формулировка ЦОД, она наиболее полно соответствует концепции ЦОД изложенной в Стандарте TIA-942 . Хотя, на мой взгляд, следовало бы уточнить формулировку «ЦОД — Это здание, его часть, или группа зданий , для которых применены… » далее по тексту. Т.к. вполне может оказаться, что при реализации ЦОД с дублированием подсистем территориально ЦОД окажется разнесён между несколькими зданиями. Иногда вспоминают и о том, что при функционировании ЦОД необходимо разработать комплекс организационных процедур и постоянно заниматься обучением персонала. Но это уже не столь принципиально, т.к. стоит только понимать, что ЦОД это не только здание, но и комплекс инженерных решений, да и не только её, а так же обеспечение необходимых сервисов и наличие квалифицированного персонала.

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

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

Относительно Стандарта TIA-942 необходимо заметить, что в документе подробно проработаны вопросы построения (в основном в форме изложений требований) инженерных подсистем, но если попытаться задаться вопросом выбора конкретного проекта для построения ЦОД, с целью выполнения конкретных задач, сразу появляются вопросы. В Стандарте TIA-942 вводится понятие уровней TIER . Стандарт рассматривает четыре уровня, связанных с разной степенью готовности (терминология TIA-942 ) инфраструктуры оборудования дата-центра. Более высокие уровни соответствуют не только более высокой готовности, но соответственно вызывают повышенные затраты на создание инфраструктуры. Фактически Стандарт TIA-942 разделяет (классифицирует) ЦОДы только по уровню надёжности (иногда пишут что по уровню доступности, но этот термин хотя и близок, но всё же он уже термина «надёжность »).

Классификация ЦОД

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

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

Можно разделить ЦОДы по:

• Назначению или точнее — разделить их на публичные и не публичные (чаще используется термин «корпоративные») ЦОДы;
• Надёжности хранения данных (если быть более точным, то по совокупности надёжности и доступности).

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

Такие «мусорные» ЦОДы в большинстве своём не соответствуют полностью требованиям к ЦОДам, но менее затратны, экологичны и аренда серверных стоек у них стоит существенно дешевле.

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

Если говорить о надёжности, то начинать нужно с рассмотрения термина «Наработка на отказ». Вообще-то не факт, что система после выхода из строя при отказе одного из своих элементов перестанет функционировать. Если при выходе со строя (переходе из работоспособного состояния в не работоспособное) одного из элементов системы, система становится неработоспособной, то говорят, что произошёл отказ . Если всё же система осталась работоспособной, то говорят, что произошёл сбой . Момент и частота появления сбоев и отказов описываются методами теории вероятности и в настоящем документе не рассматривается. Единственно о чём нужно помнить что, только анализируя схему надежности системы и имея данные о наработках на отказ в цифровом выражении каждой его составной части можно говорить уровне доступности или работоспособности всей системы. Доля (%) времени в течение года, когда система находится в рабочем состоянии и/или в состоянии простоя (% Uptime and Down time), напрямую связаны между собой. Период простоя (downtime) – это суммарный показатель простоев за год. Этими терминами часто оперируют при обсуждении различных уровней (Tier ) ЦОД. Но цифровое их выражение для разных уровней не корректно , т.к. разброс показателей отказоустойчивости у ЦОД одного уровня может быть велик. В соответствующем месте документа будет показано, что все цифры характеризующие период простоя у различных уровней ЦОД от лукавого и реально опираться на них нельзя. Если говорить кратко, то перечень наиболее характерных черт различных уровней ЦОД можно свести в простую таблицу.

Класс ЦОД (уровень)
Наиболее характерная черта	Базовый уровеньнизкая отказоустойчивость	С резервированием	С возможностью параллельного проведения профилактических работ	Высокая отказоустойчивость
	Подвержен нарушениям нормального хода работы как от плановых, так и от внеплановых действий. Он имеет системы распределения электропитанияи охлаждения компьютеров, но может иметь или не иметь фальшполов, ИБП или генератора. Если даже есть ИБП или генераторы, то они представляют собой одномодульные системы и имеют много одиночных точек отказа. Ежегодно инфраструктуру приходится полностью выключать для выполнения работ по планово-предупредительномуобслуживанию и профилактическому ремонту. Срочная необходимость может потребовать более частых отключений. Ошибки при эксплуатации или самопроизвольные отказы компонентов инфраструктуры объекта будут вызывать перерывы нормального хода работы дата-центра.	Имеются избыточные компоненты, несколько меньше подверженнарушениям нормального хода работы от плановых и от внеплановых действий, чем базовый дата-центр. В данном случае, имеется фальшпол, ИБП и генераторы, однакопроект имеет оценку N+1 (Need plus One), что означает однопоточный путь распределения по всей площади. Техническое обслуживание и ремонт критического пути электроснабжения и других частей инфраструктуры объекта потребует остановки процесса обработки данных.	Позволяет осуществлять любую плановую деятельность инфраструктуры объекта без какого-либо нарушения нормального хода работы технических средств машинного зала. К плановой деятельности относится профилактическое ипрограммируемое техническое обслуживание, ремонт и замена компонентов, добавление или удаление компонентов, влияющих на производительность, тестирование компонентов и систем и пр. Необходимо иметь в наличии достаточную мощность и распределительные возможности, чтобы одновременно нестинагрузку на одном пути и в то же время выполнять ремонт или тестирование на другом пути. Внеплановые действия, например ошибки при эксплуатации или самопроизвольные отказы компонентов инфраструктуры объекта, всё же будут вызывать перерывы нормального хода работы дата-центра. Объекты Уровня III часто проектируют с перспективой наращивания ресурсов до Уровня IV.	Имеет несколько активных путей распределения электропитания иохлаждения. Обеспечивает повышенную степень отказоустойчивости из-за наличия 2-х путей.Обеспечивает несколько путей подвода электропитания ко всемвидам вычислительного и телекоммуникационного оборудования. Требует, чтобы всё компьютерное и телекоммуникационное оборудование имело несколько силовых входов. Оборудование продолжает функционировать, когда один силовых входов отключён.Предусматривается возможность и способность инфраструктуры объекта позволять любую плановую деятельность без нарушения нормального хода работы критически важной нагрузки. Отказоустойчивая функциональность также обеспечивает способность инфраструктуры дата-центра выдержать по крайней мере один внеплановый отказ (или событие) наихудшего свойства без последствий для критически важной нагрузки. Имеет в наличии двух отдельных систем ИБП, в которых каждая система имеет резервирование N+1.
Тип компании-потребителя ресурсов	Средний и малый бизнес. ЦОД для обслуживания внутренних процессов компании	Средний и малый бизнес. ЦОД функционирует в режиме"5Х8"	Компании, обслуживающие как внутренних, так и внешних заказчиков в режиме «7Х24»	Глобальные компании, предоставляющие свои услуги в режиме «24×365»
Тип здания	C соседями		Отдельно стоящее
Количество энерговводов	1		Один активный, второй резервный	Два активных

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

Доступность, % (% UP TIME)	Время простоя в год, час. (DOWN TIME в год), час	Решения, обеспечивающие надёжность
		Без резервирования, генератора, и резервного ввода
		Без резервирования, генератора, но имеется резервный ввод
		С частичным «холодным» резервированием, без генератора но имеется резервный ввод
		С «горячим» резервированием наиболее важных частей и «холодным» практически всего остального, наличие генератора и резервного ввода
		С «горячим» резервированием наиболее важных частей и «холодным» практически всего остального, с генератором в «горячем» резерве и резервном вводе в «горячем» резерве.
99,999	5,26 мин.	Полное резервирование всего, всегда наличие 2-х путей (связей) часто с дублированием.

Запись вида «Без резервирования» не говорит о том, что в случае выхода со строя будет ожидаться заказ и получение от поставщика отказавшего блока. Наличие просчитанных запасов ЗИП и снижение значения показателя MTTR (среднее время ремонта) так же заметно влияет на время простоя.

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

Пример

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

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

Требования стандартов к составным частям ЦОД

Вначале надо определиться требованиями, каких стандартов необходимо руководствоваться, и главное — что будет, если их несколько «нарушить» соответственно в лучшую или худшую сторону. В самом начале главы, я выскажу несколько крамольную мысль. Стандарты необходимо знать, для того, что бы в случае необходимости их можно было при необходимости нарушать. Точнее обоснованно делать некоторые из требований для вашего конкретного ЦОД выше или ниже, чем требования стандарта к выбранному вами классу ЦОД. Написал я эту строку и понял, теперь точно придётся писать название этого «умного» стандарта, требованиям которого необходимо следовать при разработке ЦОД. Но… нет – не всё так просто. Документы, несущие в своём заголовке гордое имя «Стандарт…» на самом деле чаще всего являются обобщённым опытом группы экспертов создавших этот Стандарт. К доступности (% UP TIME) или времени простоя (DOWN TIME ) рекомендации не имеют прямого отношения. Следование требованиям стандартов действительно позволяет улучшить эти показатели, но на какую величину, то это является тайной покрытой мраком. Дело в том, что практически не возможно учесть все факторы, влияющие на уменьшение или увеличение этих показателей и тем более невозможно получить данные на всю, используемую конкретно вами аппаратуру вашего ЦОД. Что же делать? В первую очередь, выстроив по приоритетам требования к создаваемому вами ЦОД попытаться принять за основу один из стандартов и в дальнейшем следовать его требованиям с возможной точностью.

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

В июне 2010 года корпорация Building Industry Consulting Service International Inc. (BICSI) опубликовала новый стандарт 002-2010 : Data Center Design and Implementation Best Practices. Этот стандарт BSCI 002-2010 отражает рост сложности обустройства вычислительных центров и потребность компаний и организаций в понимании требований к энергетике, механическим нагрузкам и телекоммуникациям при проектировании инфраструктуры ВЦ.

Каким же стандартом лучше пользоваться? В чем их различия? Как же тогда сертифицироваться? Ведь существуют и стандарты от других организаций. Например, главным отличием при сертификации по стандартам Uptime Institute (Институт бесперебойных процессов) является то, что сертифицированные специалисты этой организации должны на месте убедиться в реализации требований, изложенных в своих стандартах. В середине 2010 года Uptime Institute выпустил еще один стандарт “Operational Sustainability (Операционной устойчивости)” регламентирующий и службы эксплуатации. Именно требований к службе эксплуатации не хватало в TIA -942 . И хотя совместно выполняя требования Стандарта TIA -942 и стандарта Operational Sustainability можно уже достаточно точно сформулировать требования к ЦОД, но на практике строители новых вычислительных центров чаще ссылаются на стандарт TIA-942. Дело в том, что каждый из стандартов составлялся различной организацией и во многих деталях отличаются друг от друга. Тем более что, по мнению специалистов Uptime Institute, их порядок разделения на уровни доступности никак функционально не связан с уровнями TIA-942, они оценивают способность вычислительных центров поддерживать работоспособность в условиях отказов и аварий. Чтобы избежать путаницы специалисты Uptime Institute предлагают обозначать уровни доступности в их толковании римскими цифрами I, II, III и IV. Достаточно сложно и сертифицировать ЦОД. Если обратиться к сайту Uptime Institute (сайт http://uptimeinstitute.com) то на конец мая 2012 года реально обеспечивает IV Уровень (т.е. не только документация и созданное здание с техническими средствами в нём, но и уровень эксплуатации) только 1 центр, сертификация построенного объекта на IV Tier проведена для 6 ЦОДов. Сертификация документации для построения ЦОД IV Tier получена для 22 объектов. Российских ЦОД среди Tier IV на настоящий момент нет. ЦОДов уровня III так же не очень много. Обеспечивают полное выполнение требований для III Уровня по «Операционной устойчивости» всего лишь 4 ЦОДа. Российских среди них нет . Документация и помещение соответствует Tier III у 5 российских ЦОД (4- Design Documents и 1 Constructed Facility).

В течение 2012 года будет опубликован Стандарт TIA-942-A включивший в себя изменения и дополнения следующих версий TIA-942-1 и TIA-942-2. К сожалению, новая версия стандарта сильно видоизменилась. Новый стандарт TIA-942-A будет касаться только темы кабельных систем и уже не будет таким всеобъемлющим, какой был стандарт TIA-942. Т.е. в основном он будет регламентировать только построение кабельных систем . Раздел об энергетической эффективности, скорее всего, будет касаться этой темы только с точки зрения кабельной системы и использования «зеленой» среды передачи данных – оптоволокна.

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

TIA-942-A приведен в соответствие с серией стандартов TIA-568-C в отношении топологии, терминологии и классификаций среды, представленных в стандарте 568-C.0, а также спецификаций компонентов, представленных в TIA-568-C.2 и C.3;

• Приложения, TIA-942-1 и TIA-942-2, включены в стандарт TIA-942-A;
• Информация по заземлению была перемещена из стандарта TIA-942-A в стандарт TIA-607-B;
• Информация по администрированию будет перемещена в стандарт TIA-606-B;
• Большая часть информации, касающаяся телекоммуникационных шкафов и серверных стоек, разделения силовых и телекоммуникационных кабельных систем, будет перемещена в стандарт TIA-569-C;
• Информация по внешней кабельной разводке перемещена в TIA-758-B;
• Отменено ограничение длины горизонтальных оптоволоконных кабельных систем 100 метрами.
• Кабели Category 3 и Category 5e больше не должны применяться в горизонтальных кабельных системах. В рабочей версии стандарта разрешено применение сбалансированных витых пар типа Category 6 и Category 6A в горизонтальных кабельных системах. Category 6 и Category 6A можно будет использовать и в магистральных кабельных системах;
• Одобрено применение в горизонтальных и магистральных кабельных системах многомодовых оптоволоконных кабелей типа OM3 и OM4 (многомодовый оптическое волокно с диаметром сердечника/оболочки 50/125 мкм, оптимизированное для работы с источниками света на основе лазеров на длине волны 850 нм). Кабели типа OM1 и OM2 больше не разрешаются для использования;
• Для соединения одного или двух волоконных кабелей должны использоваться волоконно-оптические разъемы типа LC и для многоволоконных разъемы типа MPO;
• В топологию ЦОД включена промежуточная распределительная зона (IDA) ;
• В стандарт добавлен раздел по энергетической эффективности;
• Добавлены термины «аппаратная розетка» (EO - equipment outlet) и «внешний сетевой интерфейс» (ENI - external network interface), заимствованные из международного стандарта ISO/IEC 24764.

Стандарт “Operational Sustainability (Операционной устойчивости)” всего лишь дополняет TIA-942 особенно в части эксплуатации ЦОД.

Стандарт «Operational Sustainability», описывает требования, позволяющие гарантировать устойчивость центров обработки данных, а также минимизировать связанные с этим риски. Как известно, предшествующий широко распространенный стандарт «Tier Standard: Topology» регламентировал технические параметры ЦОД, необходимые для достижения определенного уровня надежности. Особенность нового стандарта в том, что он учитывает человеческий фактор в устойчивой работе ЦОД. И это имеет большое значение, так как процент ошибок в работе, связанных с этим фактором достигает 70% , из них чуть более 40% связаны с ошибками управляющих службы эксплуатации. Чтобы свести к минимуму эти ошибки необходимо вести целенаправленную работу с персоналом, повышать его квалификацию, проводить мероприятия по удержанию квалифицированных кадров.

Если рассматривать стандарты от корпорации BICSI , то можно заметить, что их подход отличается от подходов к оценке уровней устойчивости других организаций.

Система оценки уровней устойчивости и основные разделы стандарта BICSI 002 2010 . Как утверждают в ассоциации, разработчики стандарта ставили перед собой цель обеспечить проектирование и строительство центров обработки данных с учетом долгосрочной перспективы их эксплуатации. Основные разделы документа:

• Планировка ЦОД
• Выбор площадки
• Архитектурные решения
• Строительные конструкции
• Электротехнические системы
• Механические системы
• Пожаротушение
• Безопасность
• Системы автоматизации здания
• Телекоммуникации
• Информационные технологии
• Ввод в действие
• Эксплуатация и техническое обслуживание
• Процесс проектирования
• Надежность

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

Uptime Institute в своё время определил четыре уровня, связанных с разной степенью готовности инфраструктуры оборудования дата-центра (ЦОД). На самом деле хоть они связаны с уровнем доступности, но наверно более правильно говорить об уровнях TIER, хотя сам термин «TIER» и переводится как — «Уровень». Выше я, не зря раскрывая понятие «Уровень», не приводил цифровые характеристики уровня доступности ЦОД. Цифровые выражения были получены только из анализа реализованных проектов. Привожу некоторые данные из документа, разработанного Институтом проблем работоспособности (The Uptime Institute) в изданном ими бюллетене «Классификация уровней по отраслевому стандарту, определяющему качество работы инфраструктуры объекта» (Industry Standard Tier Classifications Define Site Infrastructure Performance).

Параметр / Класс ЦОД (уровень)	1 Низкая отказоустойчивость			4 Высокая отказоустойчивость
Тип здания	C соседями	С соседями	Отдельно стоящее	Отдельно стоящее
Количество энерговводов	1	1	Один активный, второй резервный	Два активных
Первоначальная мощность Вт на м 2	215 - 323	430 - 537	430 — 645	537 - 860
Максимальная мощность Вт на м 2	215 - 323	430 - 537	1075- 1615	1615+
Бесперебойное кондиционирование	Нет	Нет	Возможно	Есть
Высота фальшпола в метрах	0.3	0.45	0.75 - 0.9	0.75 - 0.9
415	488	732	732+ (по страндарту 2005г 1000+)
Общая длительность отказов за год	28,8 ч	22 ч	1,6 ч	0,4 ч
Доступность ЦОД	99,671 %	99,749 %	99,982 %	99,995%
Срок ввода в эксплуатацию (мес.)	3	3 - 6	15 - 20	15 - 20
Типовой проект впервые реализован в	1965 г.	1970 г.	1985 г.	1995 г.

Общий вывод по использованию стандартов:

• Основополагающим стоит считать использование стандарта TIA — 942 с последними дополнениями (например с стандартом“Operational Sustainability (Операционной устойчивости)”;
• Новый стандарт TIA-942-A (одобрен 24 апреля 2012 года) касается только темы кабельных систем и уже не будет таким всеобъемлющим, какой был стандарт TIA-942;
• При построении ЦОД следует пользоваться не только стандартами, но и здравым смыслом, позволяющим существенно сэкономить, не ухудшая наиболее востребованные его качества;
• Сертификация более необходима коммерческому ЦОД, а ЦОД организации может этим не заниматься. Конечно если ЦОД всё, же создавался на основе стандартов, то все отступления от рекомендаций должны быть обоснованными;
• Прочитать, и, главное, понять какой Стандарт взять за основу и на какие требования его необходимо будет сделать упор в будущей разработке, нельзя считать, что работу со стандартами вы закончили. Перед тем, как переходить к следующему этапу, необходимо в обязательном порядке перечитать старые, хорошие, правда, в настоящий момент в основном забытые ГОСТы – серии 34. И ничего, что они уже много лет не обновлялись, но там есть подробное рассмотрение предпроектных стадий. В них нет находящихся на слуху слов «бизнес-процессы», «процессорный подход», но есть понятие «информационная модель» вполне корректно их заменяющее. Поэтому особенно на стадии ТЗ эти документы, вам помогут. Конечно, подходить нужно творчески и не следовать буквально всем рекомендациям, но внимательно прочитать их необходимо.

Порядок построения ЦОД

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

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

Всё будет ещё хуже. Наверно под определение «успешный» попадёт не более 20% проектов.

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

Если практически над каждым проектом довлеет вероятность провала, то, как быть с бодрыми заявлениями о десятках успешных проектов у множества фирм? Для начала нужно сразу поставить всё на свои места, определив термин «Проект ».

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

Дело в том, что существуют 2 подхода к выполнению работ и их оценке. Это подход Разработчика и подход Заказчика.

Разработчик, старается при реализации задания от Заказчика:

1. Постараться применить уже реализованное ранее Разработчиком решение;
2. В случае невозможности этого, пытается применить апробированное другими фирмами решение (чаще всего решение рекомендованное производителем оборудования или ПО);
3. Попытаться понизить требования Заказчика и по возможности свести их к тем же типовым решениям;
4. В случае неудачи предыдущего пункта Разработчик пытается увеличить время выполнения работ или сделать более мягкими требования по приёмке своей работы;
5. Попытаться на этапе приёмки сконцентрироваться на сильных сторонах выполненного проекта и скрыть свои ошибки и не доработки;
6. Попытаться побыстрее сдать проект и начать новый, или, в крайнем случае, обеспечить себе аутсорсинг.

Подход Заказчика в первую очередь характеризуется:

1. Попыткой получить, как можно больше от Разработчика и за меньшие деньги;
2. Попытками в процессе разработки проекта изменить или уточнить пункты первоначального ТЗ;
3. Во время приёмки попытаться получить как можно больше документации, и найти ошибки разработчика;
4. Постараться за счёт Заказчика не только исправить выявленные в процессе приёмки ошибки, но и внести очередные изменения в проект.

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

Существуют два варианта решений исполнения проекта по построению ЦОД. Первый предполагает выполнение проекта своими силами, а второй возлагает эти обязанности на стороннего исполнителя. В чистом виде такие схемы встречается редко. Практически всегда построение таких систем совместная работа Исполнителя (или нескольких Исполнителей) и Заказчика. Но всё упирается в вопрос, кто будет руководить проектом. Казалось бы, кому, как не Исполнителю давать такие права, но… Участие в написании ТЗ одновременно Заказчика (так как только он знает все требования к своему ЦОД) так и Исполнителя (т.к. если не привлекать Исполнителя, то Заказчик вполне может написать такое ТЗ, которое вообще никто не сможет реализовать) позволяет выработать в процессе обсуждения достаточно точное представление о системе, которая будет создаваться, и о программных средствах, которые должны применяться. Т.е. специалисты, участвующие в написании ТЗ становятся на момент окончания его написания самыми компетентными в части конкретных требований для проекта, выполняемого для конкретного заказчика. Сразу отвечаю на возможные вопросы о совместном написании ТЗ. Заказчик при разработке больших проектов может в одиночку написать только Предварительное ТЗ, годное максимально только для проведения конкурса при поиске Исполнителя. А совместно написанное ТЗ с утрясёнными между Исполнителем и Заказчиком спорными вопросами будет служить основным документом при приёмке ЦОД, так как на основе ТЗ будет писаться «Программа и методика испытаний».

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

Замечание по поводу работ относимых к компетенции комплексного отдела .

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

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

Подведение итогов по этапам обоснования и составления ТЗ

Из изложенного выше можно сделать вывод:

1. Говоря о создании ЦОД нужно в первую очередь расставить приоритет требований которым он должен будет удовлетворять.
2. После расстановки приоритетов необходимо взять за основу один из стандартов, требованиям которого вы будете следовать. (Я бы советовал использовать TIA-942 , но нельзя забывать, что он не рассматривает вопросов эксплуатации.)
3. Все отступления от стандарта в лучшую или худшую сторону должны быть обоснованны.
4. Для составления ТЗ необходимо задействовать свой отдел комплексных работ (или создать его), т.к. с вашей стороны нужны люди персонально заинтересованные в успешной реализации проекта и которые будут курировать все работы с Исполнителем.

Если вы заметили, что в этой части я рассмотрел вопросы до начала написания ТЗ, подчеркнул, что писать ТЗ нужно обязательно с Исполнителем, а о выборе исполнителя ничего не написал. Дело в том, что выбор Исполнителя отдельная и ответственная задача. И если очень кратко об этом упомянуть, то обычно выбор разбивается на 2 этапа:

1. Определение круга претендентов для решения задачи построения вашего конкретного ЦОД.
2. Анализ представленного фирмами материала и уточнение вопросов при личных встречах.

Обычно проще выбрав несколько фирм реализующих успешные проекты в этой области предоставить им предварительное ТЗ (такое ТЗ возможно составить специалистам Исполнителя). Затем кандидатов на построения ЦОД просят составить небольшой документ, вкратце описывающий все подсистемы ЦОД и процесс его эксплуатации. Обычно по полноте рассматриваемых вопросов, обоснованности решений и результатами личного общения выбор Исполнителя становится очевидным. И ещё от себя добавлю: если вам при личной встрече обещают всё и за дёшево (во всяком случае, существенно дешевле, чем у других) это повод не поверить и ещё раз проверить реальность и качество выполненных фирмой проектов. Кроме того часто в действительно сложных проектах построения ЦОД исполнение каких то его подсистем требует привлечения других фирм. В этом случае сразу нужно договариваться о том, что одна из фирм является для этого проекта системным интегратором и все технические и другие вопросы вы решете с ней. Ничего нет хуже «кусочной» реализации проекта. А то при любой неприятности всё будет как бессмертном монологе Райкина «К пуговицам претензии есть?».

»

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

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

С распространением ПК в середине 1980-х годов наметилась тенденция к рассредоточению вычислительных средств - настольные компьютеры не требовали особых условий, а следовательно, вопросам обеспечения специальной среды для вычислительной техники уделялось все меньше внимания. Однако с развитием клиент-серверной архитектуры в конце 90-х годов возникла необходимость установки серверов в специальных помещениях - серверных комнатах. Нередко случалось так, что серверы размещали на площади старых ВЦ. Примерно в это время появился термин «дата-центр» (data center), применяемый к специально спроектированным компьютерным помещениям.

Расцвет дата-центров пришелся на период бума дот-комов. Компании, которым требовались быстрый интернет-доступ и непрерывность ведения бизнеса, стали проектировать специальные помещения, обеспечивающие повышенную безопасность обработки и передачи данных, - Интернет-дата-центры (Internet Data Centers). Поскольку все современные дата-центры обеспечивают доступ к Интернету, первое слово в названии было упразднено. Со временем появилось отдельное научное направление, которое занимается вопросами оптимизации строительства и эксплуатации дата-центров.

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

За последнее десятилетие многие крупные ИТ-компании обзавелись целой сетью ЦОД. Например, старейший глобальный оператор Cable & Wireless в 2002 году купил американскую компанию Digital Island - владельца 40 ЦОД по всему миру, а европейский оператор Interoute в 2005 году приобрел оператора и хостинг-провайдера PSINet, подключив к своей панъевропейской сети 24 ЦОД.

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

Отдельные ЦОД стали занимать все бо льшие территории. Например, недавно появилась информация о том, что Google намерена построить крупный ЦОД в штате Айова площадью 22,3 га, потратив на него 600 млн долл., который заработает уже весной 2009 года.

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

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

Одновременно с этим российский оператор «Синтерра» объявил о начале одного из самых крупных проектов (не только по российским, но и по европейским меркам) - строительстве национальной сети собственных ЦОД. Проект получил название «40x40». Создав крупные дата-центры в узлах широкополосной сети в большинстве регионов России, оператор намерен превратить их в точки локализации клиентов и продаж всего спектра услуг.

До середины 2009 года в 44 центрах субъектов Федерации будут открываться вновь создаваемые ЦОД. Первыми станут Москва, Санкт-Петербург, Казань, Самара и Челябинск. Оператор планирует, что до конца 2008 года будут введены в эксплуатацию первые 20 площадок, остальные - к середине 2009-го. Интеграторами проекта являются «Крок», «Техносерв А/С» и Integrated Service Group (ISG).

Площадь каждого ЦОД, в зависимости от потребностей региона, будет варьироваться от 500 до 1000 кв.м по фальшполу и вмещать 200-300 технологических стоек. К ЦОД должны быть подключены по два кольца сети общей пропускной способностью каналов 4x10 Гбит/с, что обеспечит клиентам высокий уровень резервирования и доступности сервисов.

Проект «40x40» ориентирован на широкий круг клиентов, имеющих потребность в аутсорсинге ИТ-инфраструктуры в масштабах всей страны, - операторов связи, «сетевых» корпоративных клиентов, разработчиков контента и приложений, операторов IP-TV и телевизионных компаний, а также на госструктуры, отвечающие за реализацию национальных ИКТ-программ.

Собственные ЦОД у нас в стране имеют не только коммерческие, но и государственные структуры, такие как МВД, МЧС и ФНС.

По данным IDC, количество дата-центров в США достигнет к 2009 году 7 тыс. - по мере перевода компаниями распределенных вычислительных систем на централизованные.

Наряду со строительством новых дата-центров на повестке дня стоит проблема модернизации старых. По данным Gartner, к 2009 году 70% оборудования ЦОД перестанет отвечать эксплуатационным требованиям и требованиям к производительности, если не будет проведена соответствующая модернизация. Средний срок обновления компьютерного оборудования в ЦОД - примерно три года. Инфраструктура ЦОД проектируется с учетом срока эксплуатации порядка 15 лет.

Назначениеи структура ЦОД

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

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

ЦОД может также использоваться для предоставления услуг профессионального ИТ-аутсорсинга ИТ-решений на коммерческих условиях.

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

ИТ-инфраструктура

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

Рис. 1. ИТ-инфраструктура современного ЦОД

Рассмотрим организацию серверного комплекса и системы хранения данных.

Серверный комплекс ЦОД

Наиболее перспективной моделью серверного комплекса является модель с многоуровневой архитектурой, в которой выделяется несколько групп серверов (см. рис. 1):

• ресурсные серверы, или серверы информационных ресурсов, отвечают за сохранение и предоставление данных серверам приложений; например, файл-серверы;
• серверы приложений выполняют обработку данных в соответствии с бизнес-логикой системы; например, серверы, выполняющие модули SAP R/3;
• серверы представления информации осуществляют интерфейс между пользователями и серверами приложений; например, web-серверы;
• служебные серверы обеспечивают работу других подсистем ЦОД; например, серверы управления системой резервного копирования.

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

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

Системы хранения данных

Наиболее перспективным решением организации системы хранения данных (СХД) является технология SAN (Storage Area Network), обеспечивающая отказоустойчивый доступ серверов к ресурсам хранения и позволяющая сократить совокупную стоимость владения ИТ-инфраструктурой за счет возможности оптимального онлайнового управления доступа серверов к ресурсам хранения.

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

Рис. 2. Система хранения данных на базе технологии SAN

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

В основе концепции SAN лежит возможность соединения любого из серверов с любым устройством хранения данных, работающим по протоколу Fibre Channel (FC). Техническую основу сети хранения данных составляют волоконно-оптические соединения, FC-HBA и FC-коммутаторы, в настоящее время обеспечивающие скорость передачи 200 Мбайт/с.

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

Высокая скорость передачи данных по SAN (200 Мбайт/с) позволяет в реальном времени реплицировать изменяющиеся данные в резервный центр или в удаленное хранилище. Удобные средства администрирования SAN дают возможность сократить численность обслуживающего персонала, что снижает стоимость содержания подсистемы хранения данных.

Адаптивная инженерная инфраструктура ЦОД

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

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

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

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

Проектирование, строительство и эксплуатация ЦОД - весьма сложный и трудоемкий процесс. Существует множество компаний, предлагающих необходимое оборудование - как компьютерное, так и вспомогательное, но для построения индивидуального решения без помощи интеграторов здесь не обойтись. Созданием дата-центров в России занимается целый ряд крупных отечественных системных интеграторов, таких как IBS Croc OpenTechnologies, а также специализированные компании: DataDome, IntelinePro и др.

ЦОД и ИТ-аутсорсинг

По данным IDC, мировой рынок только хостинговых услуг в ЦОД растет очень быстро и к 2009 году составит 22-23 млрд долл.

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

Для создания собственной ИТ-инфраструктуры с нуля компаниям необходимы большие средства и высокооплачиваемые специалисты. Аренда инфраструктуры дата-центра позволяет снизить TCO за счет разделения ресурсов между клиентами, обеспечивает доступ к новейшим технологиям, дает возможность быстрого развертывания офисов с возможностями наращивания ресурсов. Для многих компаний надежность бесперебойного функционирования оборудования и сетевой инфраструктуры становится сегодня критичным фактором для функционирования бизнеса. Аутсорсинг ИТ-инфраструктуры позволяет обеспечить высокий уровень надежности данных при ограниченной стоимости, предоставляя клиентам возможность аренды серверных стоек и мест в стойке для размещения оборудования заказчика (co-location), аренды выделенного сервера (dedicated server), лицензионного ПО, каналов передачи данных, а также получения технической поддержки.

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

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

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

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

Обычно клиентам ЦОД предлагается несколько уровней обеспечения непрерывности бизнеса. В простейшем случае это размещение резервных систем в дата-центре с обеспечением должной защиты. Кроме того, может быть вариант, при котором клиенту также предоставляется аренда программно-аппаратных комплексов для резервирования. Наиболее полный вариант услуги предполагает разработку полномасштабного плана восстановления систем в случае аварии (Disaster Recovery Plan, DRP), который подразумевает аудит информационных систем заказчика, анализ рисков, разработку плана восстановления после аварии, создание и обслуживание резервной копии системы, а также предоставление оборудованного офисного помещения для продолжения работы в случае аварии в основном офисе.

Примеры коммерческих дата-центров

Дата-центры Stack Data Network

Сеть Stack Data Network объединяет три дата-центра, построенных с учетом зарубежного опыта.

Два из них (дата-центр Stack и дата-центр M1) общей емкостью 700 стоек расположены в Москве, а третий (дата-центр PSN) емкостью 100 стоек - в 100 км от столицы.

Существуют партнерские договоренности с рядом европейских дата-центров о возможности использования их ресурсов через Stack Data Network.

Дата-центры Stack Data Network предоставляют услугу обеспечения непрерывности бизнеса - disaster recovery, а также качественный хостинг: услугу collocation - размещение серверов (рис. 3) и услугу dedicated server - выделенный сервер (рис. 4).

Рис. 3. ЦОД Stack: размещение серверов
(server collocation)

Рис. 4. ЦОД Stack: аренда выделенного сервера

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

Рис. 5. ЦОД Stack: дизель-генератор

Рис. 6. ЦОД Stack: кондиционер Liebert

В сети дата-центров Stack Data Network организована круглосуточная служба эксплуатации (дежурные операторы и специалисты), в том числе по системам жизнеобеспечения. Функционируют системы круглосуточного мониторинга систем жизнеобеспечения, телекоммуникационного и серверного оборудования, сети и состояния каналов связи. Дата-центры соединены с основными телекоммуникационными узлами Москвы и объединены между собой собственными резервированными волоконно-оптическими линиями связи.

Sun Microsystems предлагает новую концепцию «ЦОД в коробке» Процесс создания традиционных ЦОД весьма затратный и длительный. Для его ускорения компания Sun Microsystems предложила решение, получившее название Blackbox («Черный ящик»). Система Blackbox монтируется в грузовой контейнер стандартной длины, в который можно упаковать до 120 серверов SunFire T2000 или до 250 серверов SunFire T1000 (в сумме - 2 тыс. ядер) либо до 250 серверов SunFire x64 (тысяча ядер), а также системы хранения, емкость которых может доходить до 1,5 Пбайт на жестких дисках и до 2 Пбайт на лентах. К контейнеру можно подключить до 30 тыс. терминалов Sun Ray. Система работает под управлением Solaris 10. Оборудование размещено в контейнере очень плотно, для циркуляции воздуха просто нет места. В связи с этим воздушное охлаждение крайне неэффективно, поэтому применяется водяное охлаждение. По данным SUN, размещение оборудования внутри грузового контейнера позволяет снизить удельную стоимость вычислительной мощности на единицу площади в пять раз по сравнению с обычным центром обработки данных. Решение Blackbox, как минимум, на порядок дешевле по сравнению с традиционной организацией ЦОД, при этом оно обеспечивает многократное ускорение процесса инсталляции. Следует отметить, что такой центр может быть реализован далеко не везде, поскольку не в каждое здание можно внести подобный контейнер. Продажа решения бала начата в этом году.

Дата-центр IBS DataFort

В 2001 году IBS и Cable & Wireless объявили о начале предоставления российским и зарубежным компаниям комплексных услуг по схеме ASP в рамках совместного проекта DATA FORT на базе дата-центра. Чуть позже DATA FORT зажил самостоятельно, а в 2003-м IBS объявила о запуске собственного ДЦ, который принадлежит дочерней компании IBS - IBS DataFort. ЦОД IBS DataFort ориентирован на обслуживание клиентов с критичными требованиями к конфиденциальности и защите данных, обеспечивает высокую степень доступности данных, современные аппаратно-программные средства, надежное энергоснабжение, скоростные каналы передачи данных и высокий уровень технической поддержки. Периметр имеет усиленную охрану (рис. 7).

Рис. 7. Охраняемая территория ЦОД IBS DataFort

Внутри здания находятся технический модуль площадью более 130 кв.м, двухэтажный резервный офис площадью около 150 кв.м, а также операторский пост. Для предотвращения рисков заливов и пожаров технический модуль дата-центра построен из стальных сандвич-панелей и поднят на полметра над уровнем пола (рис. 8).

Рис. 8. Технический модуль дата-центра IBS DataFort

Технический модуль представляет собой пожаробезопасную, сейсмоустойчивую конструкцию, оборудованную высокопрочным фальшполом, системами гидроизоляции и заземления. Модуль рассчитан на 1500 Rack-серверов, размещаемых в 19-дюймовых промышленных стойках АРС.

В дата-центре установлен автоматический комплекс газового пожаротушения, состоящий из оборудования Fire Eater, «Шрак» и ГОС «Инерген», световой и звуковой сигнализации (предупреждающей о пуске газа и требующей покинуть помещения дата-центра), а также эффективной системы дымоудаления (рис. 9).

Рис. 9. Системы пожаротушения дата-центра
IBS DataFort

Система климатического контроля (рис. 10) состоит из промышленных кондиционеров с автоматическим поддержанием заданной температуры в районе 22±0,5 °C и влажности на уровне 50±5 %, включенных по схеме N+1 (при выходе из строя одного из кондиционеров расчетные параметры всей системы не нарушаются). Приток свежего воздуха с улицы осуществляется с помощью специальной установки, препятствующей проникновению пыли внутрь дата-центра.

Рис. 10. Система климатического контроля
дата-центра IBS DataFort

IBS DataFort специализируется на услугах комплексного аутсорсинга ИТ, принимая на себя все функции ИТ-подразделений заказчика, и предлагает следующие виды услуг:

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

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

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

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

Назначение и виды ЦОД

Центры обработки данных – это сложная система, которая включает в себя целый комплекс IT решений, высокотехнологичного оборудования и инженерных конструкций.

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

Существуют две основные разновидности таких центров:

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


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

Мобильный и модульные ЦОД

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

Конструктивно система представляет собой определенное количество унифицированных модулей, которые легко объединяются в полноценный автономный комплекс и быстро настраиваются.

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

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

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

Что важно знать при выборе ЦОД?

От надежности и скорости обработки информации во многих компаниях зависит построение рабочего процесса и уровень оказания услуг клиентам.

Ключевые требования к ЦОД следующие:

• автономная работа;


• высокий уровень надежности;


• защита данных;


• безотказность;


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


• возможность расширения и модернизации (закладывается на ближайшие 5-7 лет с учетом прогнозируемого роста компании и развития технологий).

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

Сегодня Центры данных в РФ в связи с кризисом в экономике уже не настолько востребованы, как 10 лет назад, и такая тенденция прослеживается во всем мире.

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

Ключевые элементы центров данных

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

Система включает в себя следующие блоки:

• IT-инфраструктура ЦД;


• инженерные системы различного уровня сложности;


• комплексный подход к безопасности;


• управление и мониторинг.

Чтобы более подробно разобраться в структуре, следует рассмотреть основные блоки более внимательно.

IT составляющая ЦОД;

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

Это своеобразное ядро любого современного ЦОДа, которое состоит из:

• серверного оборудования;


• системы передачи, обработки и хранения данных.

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

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

Инженерные решения в ЦОД

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

Основные инженерные системы ЦОД относятся к двум категориям:

• электроснабжение. Специальное оборудование должно обеспечивать не только бесперебойную подачу электричества к оборудованию, но и в случае аварий на ЛЭП перейти на автономное питание. Для осуществления этого используют различные источники бесперебойного питания и дополнительные генераторы. Очень важно, чтобы напряжение и частота тока соответствовали необходимым параметрам и в сети не было перебоев и резких скачков. Такие перепады негативно воздействуют на серверное оборудование и могут привести к его выходу из строя;


• охлаждение. Мощные серверы во время работы выделяют огромное количество тепла, которое отводится при помощи специальных встроенных радиаторов. Это не решает проблему целиком, так как серверные станции находятся в отдельных закрытых помещениях. Чтобы обеспечить надежное охлаждение, используют различные системы кондиционирования, которые работают в автоматическом режиме, обеспечивая оптимальную температуру в помещении и препятствуя перегреву оборудования. Используя новые технологии в области кондиционирования (инверторные компрессоры, высокоточные тепловые датчики), можно добиться уменьшения затрат потребляемой электроэнергии на 10-15%.

Безопасность центров обработки данных

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

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

Мониторинг ЦОД

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

Неотъемлемой частью мониторинга являются системы прогнозирования вероятного отказа оборудования и раннего оповещения.

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

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

Центры обработки данных на выставке

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

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

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

Читайте другие наши статьи:

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

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

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

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