Риски ЦОД: выбираем месторасположение

«Избежать катастрофы может только тот, кто считает ее возможной».
В. Швебель


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

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



Мировая практика


Существует два мировых стандарта, на которых стоит ориентироваться при проектировании ЦОД: BICSI 002 2011 Data Center Design and Implementation Best Practices (6: Site selection) и TIA-942. В них предусмотрены многие факторы, оказывающие влияние на будущий дата-центр:

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

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

А как проектируют в России?


«Всякое неприятное событие неожиданно даже, если к нему готовились».
Э. Северус


Думаете, что вашему ЦОД не грозят катастрофы? – Спорное утверждение. Вот вам для размышления несколько примеров:

Июль 2013 г. В результате сильнейшей грозы в комплексе «Москва-Сити» затопило шахты лифтов и подземную парковку.
Май 2013 г. Сильным ветром в Башкирии сорвало крыши с десятка зданий, в их числе районная больница и поликлиника.
Апрель 2013 г. Из-за просадки грунта в Нижегородской области под землю ушли три здания.
Октябрь, 2011 г. Прорыв теплотрассы затопил горячей водой один из самых популярных ночных клубов в Екатеринбурге.

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

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

Кроме того, многие заказчики недостаточно ответственно подходят к проектированию серверных комнат мощностью 10 кВт, полагая, что проблем с ними меньше, чем с мегаваттным ЦОДом. Задача часто звучит как: «Мне нужно простую, маааааленькую серверную. Вот тут у меня воздуховод проходит, а тут труба отопления. Но это ничего! Да, забыл сказать, место под ЦОД у меня есть только в подвале…». Переубедить заказчика в том, что кабельные трассы и инженерные сети, не относящиеся к ЦОД, нужно вынести за пределы дата-центра, либо выбрать для серверной другое место, проектировщику бывает крайне трудно.

Как избежать ошибок? Делимся опытом


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

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

Еще одна опасность – недостаточная несущая способность строительных конструкций. Международные нормы не зря рекомендуют строить под ЦОД отдельные здания. Это в первую очередь связано с тем, что оборудование, используемое в дата-центрах имеет большой вес, значительно превышающий возможности стандартных перекрытий. Представьте, как обрадуются ваши соседи из офисов снизу, увидев вместо рабочего места своего босса (а при особенно удачном стечении обстоятельств и вместо самого босса) ваш ДГУ или ИБП. Стоит обратить особое внимание на подъездные пути и пути заноса крупногабаритного оборудования в ЦОД, в т.ч. размеры дверных проемов и грузоподъемность лифтов. Неприятно и более того, очень неудобно подавать ИБП в окно 10-го этажа с помощью автокрана или запоминать последовательность действий инженеров из Европы, по разборке супер хайэндового сервера для его заноса в здание по частям, и самое главное потом эту последовательность вспоминать при сборке. А такие ситуации, к сожалению, встречаются очень даже часто.

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

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

Желаем вам успеха при проектировании ЦОД!

В дальнейшем мы расскажем о других ошибках, которые могут повлиять на бесперебойную работу вашего дата-центра, и о том, как их избежать на последующих этапах создания.
Группа Компаний ХОСТ
18.98
Company
Share post

Comments 12

    +2
    Наличие проблем с проектированием ЦОД — недоработка программистов. Когда нормальные распределённые хранилища и NUMA наконец-таки станут мейнстримом, ЦОДы будут проектироваться исключительно по складским показателям. Проблемы с вентиляцией — отключайте нафиг, пользователи всё равно не заметят. Затопило? Беда-беда, компьютеры придётся заменить, но пользователи всё равно не заметили.
      +2
      Не знаю, как у программистов, а у строителей все просто. Например, сортировочный холодильник мясных полуфабрикатов строят с уровнем
      отказоустойчивости 100%, т.е. 0 минут простоя в год. Поставщики просто не могут позволить себе испортить 100 тон мяса глубокой
      заморозки или даже изменить температуру хранения больше чем на 1 градус. Продукты — это материальная субстанция, их, как информацию, не перекинешь на другую площадку и даже не забекапишь, за то, в отличие от информации, их можно съесть, особенно если они свежие!
      Так что требования к складам могут быть даже круче чем для ЦОДов!
      Кстати, с Днем Строителей!
        +1
        Молодец, сразу видно профессионала
        А то понавыдумывают своих тиеров первых, тиеров третьих…
          +1
          В отсутствие готового технического решения без негативных вопросов — это проблема, да.

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

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

            Поясните пожалуйста смысл сказанного.
            Если имеется в виду, что часть приложений сможет использовать распределенные вычисления, то это далеко не все приложения. Есть Business-Critical приложения больших компаний. Разместив их, скажем, на 5-ти сайтах с доступностью T2 мы не получим даже доступность T3 (99,982%).
              +1
              Т2 — это 99.741%, следовательно вероятность отказа одного ЦОД 0.259%.
              Вероятность одновременного отказа всех 5 ЦОД будет равны вероятности отказа одного, возведенная в степень 5: 0.00116546388%.
              Если вычесть из 100% полученное число, то итоговая надежность 5 ЦОД уровня Т2 будет равна 99.9988345361%, что даже больше, чем надежность Т4 ЦОДа.
              Именно так и строят надежные системы из ненадежных компонент. Другое дело, что данный расчет не учитывает внешнюю связность, но стандарты ЦОДов ее тоже не учитывают если мне память не изменяет…
                0
                Это не относится к данному расчету, но самое важное, почему такие формулы не работает в реальности, это стоимость инфраструктуры T2 и колоссальные эксплуатациионные расходы. Для того что бы формула работала нужно что бы все 5 ЦОДов имели мощность для охлаждения 100% IT нагрузки и UPS и т.п. (грубо), так же, систему электроснабжения (более 130% мощности IT нагрузки), серверы/СХД и вспомогательные системы. И их не получится ничем как бы занять на время простоя. С точки зрения бизнеса это будут деньги, закопанные с вероятностью более 99,7% бесполезно :)
                  0
                  Эти формулы на прямую не работают в реальности только из-за большей сложности создания распределенных систем и большего количества потенциальных подводных камней.

                  Стоимость решения — это критерий выбора стратегий обеспечения этой самой надежности. Либо мы строим один сверхнадежный ЦОД и миримся с тем, что он может упасть при удачном прямом попадании молнии или метеорита (или нападении экскаваторщиков, которые перекопали все окрестности) или строим несколько менее надежных площадок, разнесенных на некоторое расстояние, и обеспечивает нужный уровень девяток при помощи программных решений, зато можем пережить падение одной или нескольких площадок с плавной деградацией общей надежности системы, а не с резким ее скачком до 0%.
                0
                Есть такое business-critical приложение. База данных, от которой зависит работа бизнеса на десятки триллионов долларов.

                Называется DNS. При всех своих недостатках, с начала своей работы он ни разу не «падал» (в описанной человеком истории). Хотя если посмотреть, на каком хламе некоторые части базы данных хранятся…
                  0
                  Я просто не знаю, как рассчитать стоимость эксплуатации DNS и текущую надежность (конечно, всего сервиса DNS в совокупности). И какова реальная стоимость «хлама», включая расходы на электрич-во, охлаждения, место в стойке/на полу/под столом. Я не представляю, как сделать этот расчет. Предполагаю, что если даже часть этих расходов мала, в совокупности получится что-то очень дорогое.
                    0
                    Стоимость фантастическая. Если учесть стоимость персонала, обучения и т.д. — просто фантастическая.

                    Но и бизнес-ценность такова, что переоценить её невозможно. Ведь от работы этого приложения зависит каждый коммерческий сайт в интернете.

                    Кстати, сколько бы сравнительно (в процентах) стоил эквивалент в виде энтерпрайзного решения (дороже-больше-надёжнее) мне трудно прикинуть, но на глазок (то есть без каких-либо обоснований) я бы предположил что-то порядка 1:100 в пользу distributed.
                      0
                      Рассчитать стоимость эксплуатации и определить надежность действительно сложно, но возможно.
                      Первым делом проводится аудит на предмет текущего состояния, потом выполняется оценка по резервированию с прогнозированием рисков, а за тем описывается, что нужно сделать, чтобы данные риски хеджировать.
                      После этого можно считать стоимость, в т.ч. стоимость эксплуатации.

                      А вообще в ЦОДостроении дорого/дешево/много/мало — это все субъективные оценки, чтобы от них уйти и были придуманы стандарты Т1,2,3,4

                      А то получается, как в истории про теорию относительности. Одна блондинка во время обеда попросила Энштейна, объяснить ей теорию относительности. Он долго смотрел на нее и наконец ответил:
                      «- вот у меня на голове осталось всего три волосинки – это очень мало, но с другой стороны даже один волос в Вашем супе – это будет уже очень много …

          Only users with full accounts can post comments. Log in, please.