апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2013 / Выпуск №1 (24) / Большой проект. Cмена центра обработки данных

Рубрика: Управление проектами

Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Большой проект
Cмена центра обработки данных

С ростом и развитием вычислительных мощностей компании, а также из-за постоянно растущих требований по качеству обслуживания клиентов (SLA – Service Level Agreement) перед системными администраторами и руководителями ИТ-подразделений все чаще встает вопрос о несоответствии центра обработки данных (ЦОД) новым задачам

Зачем нужно менять ЦОД?

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

Вот примерный список причин, из-за которых системный администратор задумывается о замене ЦОД:

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

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

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

Например, минимальное время аренды сервера – один месяц, да и неделька-другая может уйти на его «строительство». А что делать, если сегодня нужно 20 серверов, к концу недели – 100, а со следующей среды – только 15?

Вот Amazon EC2 как раз идеально подходит для решения подобных задач. Специальный калькулятор – http://calculator.s3.amazonaws.com/calc5.html – позволяет сделать проектировочные расчеты, сколько может стоить та или иная «облачная конструкция».

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

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

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

Как выбрать новый центр?

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

Расход электроэнергии

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

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

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

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

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

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

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

Любое исследование нового ЦОД или переезд обязательно требуют детального анализа структуры электропотребления. Более того, тот же самый Google опубликовал на своей странице http://www.google.com/about/datacenters/efficiency/internal/#measuring-efficiency специальную форму расчетов (см. рис. 1). Кстати, довольно значительная часть расходов по электропитанию идет на… охлаждение тех самых систем и должна, безусловно, учитываться.

Рисунок 1. Эффективность дата центров Google

Охлаждение

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

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

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

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

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

В качестве решения этой проблемы допускается чередование «холодных» и «горячих» рядов.

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

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

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

Количество серверов

Наконец, немаловажным обстоятельством является количество серверов, которое надо принять во внимание. Для работы с одной стойкой (Rack), пятью стойками, выделенной «клеткой» или многими рядами серверов, столь знакомыми покартинкам из центров данных Facebook или Google, могут быть разные требования по типу, стоимости и конфигурации оборудования. Например, элементарное соединение и подключение к менеджеру нагрузки кластера в 500 веб-серверов – уже нетривиальная задача.

Существуют и специальные требования, которые могут диаметрально отличаться от клиента к клиенту.

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

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

Были и очень заманчивые варианты разместить ЦОД на большом расстоянии, но в этом случае надо непременно заручиться обязательной круглосуточной поддержкой местного персонала и иметь стопроцентную возможность удаленного доступа – ssh, KVM, ilo, Raritan – и другие способы, чтобы полностью контролировать удаленные серверы.

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

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

Подводные камни при переезде

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

• Бизнес. С точки зрения бизнеса, ИТ – лишь инструмент для работы компании. Ну, что-то типа скрипки для скрипача. Поэтому недоступность системы для бизнеса (отдел продаж, отдел клиентских отношений и т.п.) – первый «красный флажок», который надо принять во внимание. Только очень небольшое количество фирм способно закрыться на месяц, чтобы затем открыть двери в новом ЦОД. Всем остальным надо как-то продолжать существовать, чтобы нормальная деловая активность не прерывалась: клиентов надо обслуживать, грузы отгружать, бухгалтерия должна работать, а веб-сайт принимать заказы. Понятно, что достаточно сложно провести переезд, не теряя ни секунды, нолюбое время простоя надо тщательно проанализировать и объявить о нем всем партнерам и клиентам фирмы заблаговременно.
• Приложение. Мало перенести инфраструктуру в новое место, надо предусмотреть все тонкости, необходимые для работы приложения. Более подробно об этом ниже.
• Данные. Невозможно переоценить роль данных, которые находятся в компании и обслуживаются приложением. Эти данные постоянно меняются, а значит, надо, подобно жонглеру, понять, как и какие данные меняются, как их вытащить из одного ЦОД, перенести в другое место, которое может находиться на другом конце земного шара. При том, что, возможно, придется иметь дело с массивом в несколько терабайт (а может быть, и сотен терабайт), которые надо как-то втащить в другой сервер. Примем во внимание, что эти данные постоянно могут меняться в исходном ЦОД, что дополнительно усложняет задачу. Если в исходном и новом ЦОД работает однотипная база, то процесс переноса можно заметно упростить, используя Log shipping (MS SQL), master-server-репликацию (MS SQL, Mysql, PostgreSQL). Если же базы совершенно разные, то придется думать, как перенести данные с минимальными временными потерями.
• Инфраструктура. Необходимо тщательно подготовиться к запуску новой инфраструктуры. Вполне возможно, что придется какое-то время оплачивать услуги как старого, так и нового ЦОД. Более того, в этом случае скорее всего следует научить и текущее приложение работать сразу на два ЦОД.
• Сеть. Вряд ли удастся полностью перенести текущую сетевую топологию в новый ЦОД. Идеальнее всего, если будет использоваться то же оборудование. В этом случае можно просто скопировать целые куски из конфигурации иперенести их из старого в новое место. А вот как быть, если в старом ЦОД установлены менеджеры нагрузки (load balancers) Big IP F5, а в новом – Cisco Content Switch или Citrix Netscaler? Топология и внутренние особенности работы уних достаточно разные – это надо обязательно принять во внимание.

Дьявол в деталях

Во время интервью претенденту на должность системного администратора часто задается вопрос с открытым ответом: «Что происходит, когда в адресной строке веб-браузера вы набираете www.google.com? Как можно подробнее, пожалуйста, до обеда мы должны успеть...» Понятно, что на этот вопрос можно отвечать и 10 минут, и 10 часов. Чтобы полноценно начать планировать переезд в новый ЦОД, каждый системный администратор должен достаточно четко представлять, как его текущий ЦОД обслуживает запросы типа www.bigcompany.com/user. Что обрабатывает веб-сервер, куда и как он перенаправляет запросы, как подключается база данных, как используются менеджер нагрузки имежсетевой экран и многие десятки, а может быть, и сотни небольших «кирпичиков», совместная работа которых делает то, что называется «функциональность системы» (см. рис. 2).

Рисунок 2. Совместная работа системных компонентов

Менеджеры нагрузки (Load balancers) в современных ЦОД выполняют функции, значительно выходящие за рамки простого распределения веб-трафика, используя тот или иной алгоритм – «раунд-роббин», минимальная нагрузка, минимальное количество соединений и т.п. Например, в зависимости от адресной строки, передаваемой на веб-сервер, менеджер нагрузки может решить, на какой адресный пул – группа серверов «А» или группа серверов «Б» – перенести это соединение. Для этого на менеджерах нагрузки фирмы Big IP F5 используют так называемые iRules, которые достаточно нетривиальны в программировании.

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

А еще может, например, всплыть момент, что в текущем ЦОД работает Windows IIS, которая безразлична к тому, используется ли ВЕРХНИЙ РЕГИСТР в именах файлов или нет, а с точки зрения Apache THEFILE.TXT и TheFile.txt, thefile.txt – три совершенно разных имени файлов. Поэтому приходится вставлять специальный шаг «декапитализации» в процесс миграции данных из одного ЦОД в другой.

***

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

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

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

1. Кондаков К. Поддержка системы 24х7. Организация круглосуточной работы ИТ-отдела. //«Системный администратор», №9, 2011 г. – С. 108-112 (http://samag.ru/archive/article/1429).
2. Бирюков А. ЦОД: создаем систему ИБ. Требования и правила построения. //«Системный администратор», №7-8, 2011 г. – С. 68-71.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи