Это важный вопрос для определения концепции будущего ЦОД и, следовательно, принципов построения службы эксплуатации.
Если в случае коммерческого ЦОД уровень предоставляемой клиенту услуги очевиден и зафиксирован в договоре, то в случае корпоративного ЦОД зачастую бывает так, что текущие требования потребителя и его будущие потребности заранее не определены.
В рамках консультационной практики у нас был пример, когда одна финансовая организация, не рассматривающая перемещение мощностей своих ЦОД на коммерческую площадку, хотела организовать внутренние процессы по стандарту TS: OS – Tier Standard: Operational Sustainability[17].
В ходе первичных консультаций при определении объемов задач и текущей ситуации в организации выяснилось, что внутренние требования к ЦОД своих же внутренних клиентов – ИТ-отдела – никак не зафиксированы и даже не определены, а существуют на уровне «должно работать». Более того, люди, которым поставлена задача привести эксплуатацию ЦОД в соответствие со стандартом TS: OS, слабо ориентируются в подразделениях компании, являющихся их внутренними заказчиками. Соответственно, оказалось невозможным как выстроить концепцию функционирования ЦОД и службы эксплуатации, так и определить объем и квалификацию персонала, который требовался для работы ЦОД.
Какие из этого проистекают проблемы для проектировщиков и службы эксплуатации:
• Если мы не знаем, допускает ли ЦОД технологические перерывы в работе и какова приемлемая длительность таких перерывов, мы не можем оценить достаточность уровня резервирования инфраструктуры.
• Если мы не знаем логику работы приложений, то мы также не можем оценить достаточность уровня резервирования инфраструктуры, ведь организация, имея два ЦОД, вполне может использовать их как основной и резервный. При такой схеме в случае аварии в одном из ЦОД используется другой, обладающий репликами[18] приложений.
• Мы не можем понять, какая численность службы эксплуатации требуется, так как непонятно, нужно ли держать инженеров на объектах 24 × 7.
• Не зная требований к непрерывности, мы не можем понять требования к подрядчикам по обслуживанию сложных и критических узлов инженерной инфраструктуры, установить сроки реагирования на неисправности, установить количество необходимого ЗИП[19] на складе.
Во избежание всех указанных проблем и неясностей во взаимодействии необходимо определить, сформулировать и зафиксировать уровень сервиса между ЦОД и клиентом, внутренним или внешним.
Теперь Вам стала понятна важность определения уровня сервиса между ЦОД и клиентом. Для этого требуется составление и проведение формальных процедур принятия обеими сторонами документов, называемых SLA или OLA.
SLA (Service Level Agreement), соглашение об уровне услуг, – это документ, характерный прежде всего для ЦОД колокейшн-провайдера, заключаемый между заказчиком и исполнителем, описывающий параметры предоставляемой услуги или сервиса.
SLA с клиентом чаще всего характеризуется требованиями к параметрам окружающей среды, указанным производителями оборудования и используемым клиентами ЦОД. Эти параметры необходимо учитывать в максимально широком диапазоне, чтобы иметь возможность эксплуатировать оборудование с более строгими параметрами по температуре и влажности.
Также существует OLA (Operational Level Agreement), соглашение об уровне операционного обслуживания, – аналогичный SLA внутренний документ компании, определяющий параметры услуги, оказываемой друг другу внутренними подразделениями компании.
• При соотнесении требований этих документов важно учитывать три аспекта:
• требования к любым SLA должны быть более жесткими по сравнению c OLA;
• требования к SLA ваших подрядчиков и поставщиков услуг должны быть более жесткими или как минимум равными с SLA, заключенными вами с клиентом;
• в договорах с подрядчиками и поставщиками услуг необходимы санкции за нарушение SLA, симметричные санкциям от клиентов ЦОД.
Если данные условия не соблюдаются, это может приводить к негативным событиям. Например, согласно SLA ваш поставщик услуг связи может допускать перерыв в предоставлении услуг на два часа в месяц без санкций, а по SLA с вашим клиентом допусти́м перерыв лишь в один час; это означает невозможность выполнения условий контракта с клиентом вашего ЦОД.
Отделы внутри компании также взаимозависимы и используют внутренние сервисы, параметры которых должны быть описаны. Важность наличия внутренних задокументированных взаимоотношений с разными отделами трудно переоценить. Несмотря на этот, казалось бы, формализм подхода, у вас будут четкие критерии того объема работы и уровня сервиса, который вы предоставляете другим. Информация не останется на уровне «договоренностей в почтовой переписке» между сотрудниками компании, которые могут ее покинуть и не оставить следов договоренностей. Также, опираясь на задокументированные условия OLA, можно обосновать те или иные затраты на резервирование и уровень обслуживания вашей инфраструктуры.
Например: для корпоративного ЦОД планировалась установка сетевого оборудования одного из вендоров. Выяснилось, что данному оборудованию присущи технологические особенности, а именно – подача охлаждающего воздуха к нему осуществляется от одной боковой стороны к другой, а также низкая температурная устойчивость: при 35 °C уже фиксировался перегрев. Эксплуатационной команде ЦОД пришлось не только демонтировать все боковые стенки уже установленных стоек холодных коридоров, но и понижать температуру подаваемого холодного воздуха до минимально возможной в 16 °C, чтобы сохранить температуру в пределах рабочего диапазона этого сетевого оборудования.
Для ЦОД крайне важно понимать требования SLA с клиентами и, исходя из них, иметь определенные зафиксированные SLA с поставщиками, так как это напрямую влияет на жизнеспособность ЦОД. SLA с поставщиками должны давать возможность ЦОД обеспечить SLA перед клиентами. Поэтому важно иметь фиксированные и прозрачно измеряемые метрики, по которым клиенты могут оценить качество и непрерывность предоставляемых им сервисов ЦОД.
В контексте данной книги мы не будем рассматривать все составляющие SLA между клиентом и ЦОД, так как это в основном коммерческие вопросы. В любом случае в SLA будут присутствовать требования о непрерывности подачи электроэнергии в каком-либо виде, допустимые диапазоны температуры и влажности. Так как это коммерчески значимая информация, все цифры должны иметь различные инструментальные источники подтверждения параметров, указанных в SLA (BMS[20], поверенные средства измерения и т. д.).
Обрисуем параметры SLA по отдельности.
1. Подача электроэнергии
Очевидно, что электропитание – самый критичный параметр, который требуется обеспечивать службе эксплуатации. Его потеря или даже ухудшение параметров на доли секунды приводит к отключениям.
Например: в одном из крупных ЦОД были установлены слишком широкие параметры ИБП по допустимому диапазону частоты (50 ± 4 Гц). Это не было отслежено на этапе ПНР, и в итоге при частоте ниже 47 Гц у клиентов стало перезапускаться оборудование при сохранении электропитания в стойке. Сложность выявления этой проблемы заключалась в том, что не все оборудование реагировало на изменения частоты, что не позволяло однозначно идентифицировать проблему на стороне инженерной инфраструктуры ЦОД.
В зависимости от коммерческих условий процент непрерывности подачи электроэнергии может быть разным. Также могут существовать дополнительные условия, по которым предусмотрена ответственность за работу только одного ввода питания или обоих (если вводов питания два).
Тем не менее есть важные моменты, которые службе эксплуатации следует учитывать в любом случае: даже если вы имеете договорные отношения с клиентом о том, что вы обеспечиваете непрерывность только одного ввода из двух (а это стандартное условие для большинства ЦОД), то в случае неверно организованных клиентом подключений внутри стойки с неправильным распределением парных нагрузок часть оборудования может отключаться. Это вызовет негативную реакцию клиентов на работу ЦОД, несмотря на то, что юридически вы будете правы.
Во избежание этого мы рекомендуем:
• проводить информирование клиентов о способах правильного подключения. В качестве соответствующих мер можно предложить размещение информационных плакатов в машинном зале, проведение совместных аудитов подключений с электриком ЦОД;
• обеспечить проактивный мониторинг обычных и парных нагрузок на PDU. Это позволит информировать об угрозе ошибки при приближении к критическим параметрам.
2. Температура
Температура не так критична, как электропитание, и незначительные ее колебания не приведут к немедленной остановке работы ИТ- и телеком-оборудования. Тем не менее это также важнейший параметр ЦОД, зафиксированный в SLA с клиентом.
Традиционно для России и СНГ клиент ЦОД видит этот параметр в пределах температуры 22 ± 2 °C. В современных реалиях производители серверного оборудования расширяют диапазоны приемлемых температур, и этот параметр теоретически может быть увеличен до 26 ± 2 °C. Для его изменения следует избавиться от всего серверного и телекоммуникационного оборудования, требующего прежних параметров, и обновить SLA/OLA в договорах с клиентами.
Так, например, все европейские ведущие колокейшн-провайдеры уже несколько лет работают в новых диапазонах. Это, разумеется, ведет к экономии средств, затрачиваемых на охлаждение, что в пересчете на десятки и сотни мегаватт складывается в весьма значительные суммы.
На наш взгляд, российский консерватизм имеет исторические корни, следуя традиции использования «из поколения в поколение». Зачастую сами клиенты ЦОД не представляют, почему им необходимы именно эти параметры, – они это где-то слышали, прочитали и т. п.
Если посмотреть на эволюционные изменения температур от ASHRAE[21], можно понять, что когда-то это было действительно актуально, но за прошедшие годы изменилось практически все, кроме сознания людей.
Сравнение версий рекомендованных параметров воздуха от 2004, 2008/2011, 2015 и 2021 гг.
Даже если технически возможно повысить температуру охлаждающего воздуха, раз вы представляете коммерческий ЦОД, вы должны будете учитывать настроения клиентов, которые могут выбрать другого провайдера только потому, что «у него холоднее».
С точки зрения службы эксплуатации также лучше тем или иным способом обеспечить более низкую температуру для ИТ-оборудования, так как у вас будет больше времени на реакцию и предотвращение аварий, вызванных перегревом оборудования. В любом случае необходимо помнить о балансе между экономикой и эксплуатацией.
3. Влажность
Влажности уделяется традиционно меньшее внимание. Все знают, что при низкой влажности в зимнее время есть риски повреждения оборудования статическим электричеством. Но это теория, а на практике ЦОД с антистатическими фальшполами и работающим заземлением – не то место, где накапливается статика.
С высокой влажностью борются еще меньше: считается, что система кондиционирования осушает воздух и влажность не может достигнуть пределов, опасных для оборудования. Тем не менее также не стоит доводить влажность до крайних значений.
Например: при запуске одного корпоративного ЦОД стояли четкие сроки начала тестовых испытаний ИТ-систем. К моменту, когда все было готово, система вентиляции и кондиционирования еще не функционировала из-за сложностей с поставками. Тем не менее было принято решение запускать ЦОД без охлаждения, так как изначальная мощность ИТ-оборудования не прогревала пространство ЦОД настолько, чтобы требовалось теплоотведение. При этом влажность была свыше 90 % – характерная для субтропического климата. Спустя несколько месяцев на серверном оборудовании, которое работало в таких условиях, стали появляться «синие экраны смерти». Опытным путем было установлено, что вследствие большой влажности произошло окисление планок памяти. Далее, после запуска систем кондиционирования и вентиляции, такого более не происходило.
На практике влажность трудно поддерживать в заданных режимах. И если вам повезло не иметь ограничений данного параметра в SLA – просто избегайте экстремальных значений в обе стороны, руководствуясь теми же современными требованиями ASHRAE.
Если же в SLA указаны параметры влажности – надо стремиться их соблюдать. Зимой помогают пароувлажнители, летом влага конденсируется на теплообменниках кондиционеров и происходит осушение воздуха. Если на улице экстремальные условия и возможностей системы кондиционирования недостаточно, то остается одно – выключить приточную вентиляцию. К этому способу прибегают нечасто, но он помогает вернуть показатели влажности в рамки SLA, хотя и в ущерб свежести воздуха в серверном помещении.
При определении параметров SLA следует учитывать сроки реакции ваших поставщиков (например, сервисных компаний, провайдеров) на какое-либо аварийное событие, то есть время реакции поставщика в SLA должно быть меньше времени возможного прерывания сервиса ЦОД для клиента.
На практике это фактически нереально из экономических соображений: чем короче сроки реакции, тем выше стоимость сервисного контракта. Можно даже организовать круглосуточные службы поддержки поставщиками на площадке ЦОД с проживанием, но это приведет к невероятной стоимости контракта.
Что делать в этом случае? Предотвращать возможные проблемы различными компенсирующими мерами.
Например: SLA с компанией, осуществляющей ремонт ИБП, оговаривает срок прибытия в ЦОД в пределах 4 часов, а восстановления – не более 8 часов. У вас выходит из строя один из ИБП, и один из вводов остается без гарантированного питания от ИБП. Какие меры может предпринять служба эксплуатации своими силами, чтобы обеспечить бесперебойную работу в таких условиях?
• Заранее определить компоненты, способные выйти из строя, и иметь их на складе в ЦОД.
• Запустить ДГУ на 8 часов, то есть на максимальное время восстановительных работ по SLA, чтобы второй ввод имел гарантированное питание до момента устранения неисправности.
• Заранее обучить персонал работе с оборудованием и провести тестовые тренировки по ликвидации аварийных ситуаций.
• Применять типы ИБП, позволяющие заменять узлы модулями в горячем режиме, без необходимости отключения оборудования, силами дежурной смены (без выезда сервис-инженера) для экономии средств и времени.
Разумеется, эти действия потребуют подготовительной работы руководителей службы эксплуатации. Но тем самым грамотно и спланированно, при сохранении высокого уровня доступности будет достигнута значительная экономия бюджета – по сравнению со стоимостью контракта с вендором/поставщиком на поддержку такого же уровня.