Многие предприятия работают за рамками безопасных пороговых значений мощности, практически не располагая достаточным пространством для расширения. По данным IDC, средний период эксплуатации центра обработки данных составляет 9 лет. Однако, по мнению Gartner, любой объект старше 7 лет считается устаревшим. Переполненные или устаревшие центры обработки данных создают препятствия для растущих организаций, и строительство новых центров обработки данных иногда является единственным решением. Несмотря на то, что скорость вывода продукции на рынок критически важна для успеха, компании, которые не способны должным образом оценить потребности своего бизнеса, будут создавать неэффективные центры обработки данных, не способные обеспечить бесперебойную работу или удовлетворить будущие бизнес-потребности
Как избежать серьезных ошибок при строительстве и расширении центров обработки данных?
Ключевым фактором является выбор методологии проектирования и строительства центров обработки данных. Зачастую компании основывают свои планы на мощности на квадратный метр, стоимости производства на квадратный метр и уровне Tier — критериях, которые могут не соответствовать общим бизнес-целям и профилю рисков. Некачественное планирование приводит к неэффективному использованию ценного капитала и может увеличить эксплуатационные расходы.
Многие организации перегружены работой, сосредотачивая внимание на технических деталях, инициативах по защите окружающей среды, параллельном техническом обслуживании, эффективности энергопотребления (PUE) и сертификации Лидерства в энергетическом и экологическом проектировании (LEED). Все эти критерии являются критически важными в процессе принятия решений. Однако детали часто затеняют общую картину. Большинство компаний упускают бизнес-возможности, обеспечиваемые расширением центра обработки данных, основанным на целостном подходе.
Несмотря на то, что в этой области доступно множество консультантов, которые помогут вам найти свой путь, оценка идей и предложений может оказаться невыполнимой задачей. В эту категорию рисков могут попасть организации, которым требуется критическая мощность в диапазоне 1–3 мегаватт. Критическая природа пользователей инфраструктуры среднего размера не менее важна, чем мега-пользователей; однако внутренний технический опыт, необходимый для реализации надлежащих планов расширения, может быть ограничен. В результате происходит перегрузка информацией из нескольких источников, что приводит к путанице и неэффективному принятию решений.
"Владельцы центров обработки данных сейчас сталкиваются со множеством проблем. Их активы критически важны, но не обеспечен их надлежащий контроль. Энергопотребление обходится им в целое состояние. Они не могут обеспечить охлаждение имеющегося оборудования и снизить риск катастрофического отключения. И если они принимают решение вложить средства, то к моменту строительства активы уже устаревают", – Stanford Group
Как избежать серьезных ошибок при строительстве и расширении центров обработки данных?
Ключевым фактором является выбор методологии проектирования и строительства центров обработки данных. Зачастую компании основывают свои планы на мощности на квадратный метр, стоимости производства на квадратный метр и уровне Tier — критериях, которые могут не соответствовать общим бизнес-целям и профилю рисков. Некачественное планирование приводит к неэффективному использованию ценного капитала и может увеличить эксплуатационные расходы.
Многие организации перегружены работой, сосредотачивая внимание на технических деталях, инициативах по защите окружающей среды, параллельном техническом обслуживании, эффективности энергопотребления (PUE) и сертификации Лидерства в энергетическом и экологическом проектировании (LEED). Все эти критерии являются критически важными в процессе принятия решений. Однако детали часто затеняют общую картину. Большинство компаний упускают бизнес-возможности, обеспечиваемые расширением центра обработки данных, основанным на целостном подходе.
Несмотря на то, что в этой области доступно множество консультантов, которые помогут вам найти свой путь, оценка идей и предложений может оказаться невыполнимой задачей. В эту категорию рисков могут попасть организации, которым требуется критическая мощность в диапазоне 1–3 мегаватт. Критическая природа пользователей инфраструктуры среднего размера не менее важна, чем мега-пользователей; однако внутренний технический опыт, необходимый для реализации надлежащих планов расширения, может быть ограничен. В результате происходит перегрузка информацией из нескольких источников, что приводит к путанице и неэффективному принятию решений.
"Владельцы центров обработки данных сейчас сталкиваются со множеством проблем. Их активы критически важны, но не обеспечен их надлежащий контроль. Энергопотребление обходится им в целое состояние. Они не могут обеспечить охлаждение имеющегося оборудования и снизить риск катастрофического отключения. И если они принимают решение вложить средства, то к моменту строительства активы уже устаревают", – Stanford Group
Ошибка 1: На этапе проектирования центра обработки данных не учитывается совокупная стоимость владения (TCO)
Сосредоточение внимания исключительно на капитальных затратах является простой ловушкой; расходы, необходимые для строительства или расширения, могут быть ошеломляющими. Моделирование капитальных затрат имеет решающее значение, однако если вы не учли затраты на эксплуатацию и обслуживание (OpEx) инфраструктуры ваших критически важных для бизнеса объектов, вы существенно обсчитали весь процесс эффективного бизнес-планирования.
Для моделирования расходов на эксплуатацию центра обработки данных требуется два важнейших компонента: затраты на обслуживание и эксплуатационные расходы. Затраты на техническое обслуживание — это расходы, связанные с надлежащим техническим обслуживанием всей критически важной поддерживающей инфраструктуры предприятия. Они включают в себя, среди прочего, контракты на техническое обслуживание оборудования OEM-производителей, расходы на уборку центра обработки данных и затраты на субподрядчиков, выполняющих ремонт и модернизацию. Эксплуатационные расходы — это расходы, связанные с повседневной эксплуатацией и персоналом на объекте. Они включают в себя, помимо прочего, укомплектованность кадрами, программы обучения и обеспечения безопасности персонала, создание документации по эксплуатации конкретного объекта, управление ресурсами, а также политики и процедуры обеспечения/контроля качества. Если вы не рассчитали трех-семилетний бюджет на эксплуатацию и обслуживание (O&M), вы не сможете создать модель окупаемости инвестиций (ROI), которая поддерживает умные бизнес-решения
Если вы планируете строительство или расширение центра обработки данных, критически важного для бизнеса, ваш лучший подход — сфокусироваться на трех основных параметрах совокупной стоимости владения: 1) капитальные расходы, 2) расходы на эксплуатацию и техническое обслуживание и 3) затраты на электроэнергию. Не оставляйте компоненты без учета, иначе вы рискуете создать модель, которая не соответствует профилю риска вашей организации и профилю торговых издержек. Если вы принимаете решение о "покупке" (использовании колокации/хостинга) или создании собственной системы, риск непринятия такого подхода к совокупной стоимости владения значительно возрастает.
Для моделирования расходов на эксплуатацию центра обработки данных требуется два важнейших компонента: затраты на обслуживание и эксплуатационные расходы. Затраты на техническое обслуживание — это расходы, связанные с надлежащим техническим обслуживанием всей критически важной поддерживающей инфраструктуры предприятия. Они включают в себя, среди прочего, контракты на техническое обслуживание оборудования OEM-производителей, расходы на уборку центра обработки данных и затраты на субподрядчиков, выполняющих ремонт и модернизацию. Эксплуатационные расходы — это расходы, связанные с повседневной эксплуатацией и персоналом на объекте. Они включают в себя, помимо прочего, укомплектованность кадрами, программы обучения и обеспечения безопасности персонала, создание документации по эксплуатации конкретного объекта, управление ресурсами, а также политики и процедуры обеспечения/контроля качества. Если вы не рассчитали трех-семилетний бюджет на эксплуатацию и обслуживание (O&M), вы не сможете создать модель окупаемости инвестиций (ROI), которая поддерживает умные бизнес-решения
Если вы планируете строительство или расширение центра обработки данных, критически важного для бизнеса, ваш лучший подход — сфокусироваться на трех основных параметрах совокупной стоимости владения: 1) капитальные расходы, 2) расходы на эксплуатацию и техническое обслуживание и 3) затраты на электроэнергию. Не оставляйте компоненты без учета, иначе вы рискуете создать модель, которая не соответствует профилю риска вашей организации и профилю торговых издержек. Если вы принимаете решение о "покупке" (использовании колокации/хостинга) или создании собственной системы, риск непринятия такого подхода к совокупной стоимости владения значительно возрастает.
Ошибка 2: Недостаточная оценка затрат на строительство
Еще одна распространенная ошибка — это сама оценка. Финансовые запросы на расширение или строительство ЦОДа, направляемые в советы директоров, часто бывают слишком низкими и приводят к провалу. Процесс принятия решений выглядит примерно так:
• Запрос на капитал подается и предварительно утверждается. Выделяются финансовые ресурсы на проведение расследований, сбор данных и создание фактического бюджета.
• Затрачивается время на управление вышеупомянутым процессом подготовки и рассмотрения бюджета.
• Результаты показывают, что первоначально запрошенный бюджет слишком мал.
• Реализация проекта задерживается. Это влияет на работу сотрудников, а также на способность предоставлять услуги внутренним и внешним клиентам и потенциальным клиентам.
• Таким образом, вы замыкаете круг, вернувшись к самой большой ошибке № 1: неиспользование подхода к совокупной стоимости владения и отсутствие целостной финансовой модели.
Затрат на ошибки строительства можно легко избежать, но они обречены на провал, если вы попадете в ловушку № 3.
"Организации с критическими требованиями к мощности в диапазоне 1–3 мегаватт могут попасть в эту категорию риска" — Майк Манос, эксперт в области промышленности
• Запрос на капитал подается и предварительно утверждается. Выделяются финансовые ресурсы на проведение расследований, сбор данных и создание фактического бюджета.
• Затрачивается время на управление вышеупомянутым процессом подготовки и рассмотрения бюджета.
• Результаты показывают, что первоначально запрошенный бюджет слишком мал.
• Реализация проекта задерживается. Это влияет на работу сотрудников, а также на способность предоставлять услуги внутренним и внешним клиентам и потенциальным клиентам.
• Таким образом, вы замыкаете круг, вернувшись к самой большой ошибке № 1: неиспользование подхода к совокупной стоимости владения и отсутствие целостной финансовой модели.
Затрат на ошибки строительства можно легко избежать, но они обречены на провал, если вы попадете в ловушку № 3.
"Организации с критическими требованиями к мощности в диапазоне 1–3 мегаватт могут попасть в эту категорию риска" — Майк Манос, эксперт в области промышленности
Ошибка 3: Неправильная установка критериев проектирования и рабочих характеристик
Существует два ошибочных шага, которые могут привести к масштабным перерасходам средств вашей организации. Во-первых, все хотят иметь проект, соответствующий требованиям Tier 3, но не всем он нужен. Во-вторых, большинство представлений о киловаттах на квадратный фут или стойку не поддерживаются реальными бизнес-требованиями. Неоднократно подход "должен иметь мощность 300 Вт на квадратный фут" был неоправдан. Не стройте слишком большой объект; это напрасная трата капитала. Предприятия более высокого уровня Tier также требуют повышенных расходов на эксплуатацию и электроэнергию. Это делает всю основу для надлежащей бизнес-модели и возврата инвестиций неправильной. Сначала необходимо определить правильные критерии проектирования и рабочие характеристики. Затем на их основе следует определить ваши капитальные и эксплуатационные расходы. Перед посещением совета директоров убедитесь в правильности критериев проектирования и установленной финансовой модели. Более подробную информацию о параметрах проектирования см. в информационной статье № 142 "Проекты центров обработки данных: Планирование системы".
Ошибка 4: Выбор площадки до определения критериев проектирования
Организации часто начинают искать оптимальное пространство, прежде чем будут установлены критерии проектирования и рабочие характеристики. Без этой важной информации не имеет смысла тратить время на посещение или рассмотрение нескольких объектов. Этот типичный сценарий "ставить телегу впереди лошади" часто характерен для пользователей в диапазоне 1–3 мегаватт. В то время как мега-пользователи обычно являются экспертами в этой области и учитывают доступность и стоимость электроэнергии, оптоволокно, географические проблемы, такие как землетрясения, торнадо и наводнения и т. д., базовые пользователи часто имеют бизнес-модели, которые диктуют необходимость строительства или обновления здания в их основном регионе бизнеса. Проблема с выбором площадки преждевременно или на основе узкой географии заключается в том, что площадка часто не отвечает требованиям к проектированию. Например, размещение центра обработки данных на два этажа ниже вашего офиса в высотном здании или даже в двух кварталах от него весьма удобно, но для ЦОДов, критически важных для бизнеса, требуется длинный список критериев, которые обычно невозможно выполнить в пространстве с несколькими арендаторами без значительно более высоких затрат на строительство или ограничений пространства для будущего расширения. В информационной статье №81 "Выбор площадки для критически важных объектов" содержится дополнительная информация, которая поможет избежать этой большой ошибки. В некоторых организациях критерии поиска площадки определяются на основе площади фальшпола, необходимой для размещения критически важной ИТ-инфраструктуры. Это может привести к следующей большой ошибке
"Хотя физический проект центра обработки данных критически важен, эксплуатация и обслуживание объекта играют более важную роль в обеспечении доступности площадки" — The Uptime Institute
"Хотя физический проект центра обработки данных критически важен, эксплуатация и обслуживание объекта играют более важную роль в обеспечении доступности площадки" — The Uptime Institute
Ошибка 5: Планирование пространства до того, как будут установлены критерии проектирования центра обработки данных
Может потребоваться значительная площадь для размещения компонентов инфраструктуры центра обработки данных. В самых надежных системах соотношение между фальшполом и опорными конструкциями может достигать 1 к 1. Многие организации основывают свои требования к пространству только исходя из ИТ-оборудования. Однако для установки механического и электрического оборудования также требуется значительное пространство. Кроме того, многие организации игнорируют площадь, необходимую для размещения офисных помещений, баз оборудования и помещений для размещения ИТ-оборудования. Поэтому крайне важно определить критерии проектирования перед разработкой плана помещения. Без этого невозможно составить концептуальное представление об общей площади, необходимой для удовлетворения ваших потребностей в целом.
Ошибка 6: Тупиковый проект
Отрасль центров обработки данных успешно продвигает важность модульных проектов. Однако использование модульного подхода не гарантирует успех. Модульные подходы основаны на добавлении "блоков" дополнительного инфраструктурного оборудования по мере необходимости для сохранения капитала. Организации по-прежнему загоняют себя в тупик, тщетно пытаясь предсказать будущие потребности. Но это может измениться. Модульные и гибкие проекты являются ключом к успеху в долгосрочной перспективе. Даже самое лучшее в решение по планированию киловатт на количество стоек/квадратный метр может устареть в результате консолидации, экспоненциального роста бизнеса за счет приобретения или резкого перехода к незапланированной площади с высокой плотностью установки. С точки зрения электрической установки следует убедиться, что проектное решение позволяет добавлять мощности ИБП к существующим модулям без отключения питания. Проектируйте системы распределения входных и выходных данных в соответствии с будущими изменениями в базовых конструктивных решениях. Затраты на избыточное распределение для будущих потребностей в емкости не являются существенными при моделировании совокупной стоимости владения. С точки зрения механического оборудования большинство пользователей может удовлетворить свои потребности в охлаждении с помощью традиционного охлаждения по периметру, с надлежащей высотой пола и планировкой горячих/холодных коридоров. Однако одно развертывание с высокой плотностью может изменить все. Убедитесь в том, что базовая конструкция обеспечивает гибкое (без остановки работы) внедрение индивидуальных решений для охлаждения в стойки/ряды.
Ошибка 7: Недопонимание PUE
Эффективность энергопотребления (PUE) — это эффективный инструмент для повышения и измерения эффективности. Однако амбициозные заявления об энергоэффективности могут привести к значительному недопониманию. Практически во всех ситуациях, когда речь идет о новом строительстве и расширении, существуют капитальные затраты, связанные с достижением более низкого показателя PUE. Часто организации ставят цель PUE с правильными намерениями, но расчет не учитывает все необходимые факторы. Чтобы достичь поставленных целей, нужно в полной мере понимать, какой возврат инвестиций приходится на капитальные расходы. Вы должны спросить себя, какова совокупная стоимость владения относительно целевого показателя PUE?
Существует множество способов проиллюстрировать и понять распределение баланса между показателями PUE, ROI и TCO. Ниже приведены три наглядных примера, представляющие просчет или недопонимание.
• Какой день использовался в качестве "критерия проектирования" для расчета? Расчеты или измерения были выполнены в "идеальный день"? Или расчет был основан на среднегодовом значении?
• Был ли расчет основан на полностью или частично загруженном рабочем состоянии центра обработки данных? Все кривые эффективности оборудования изменяются в зависимости от профилей нагрузки. В реальных рабочих условиях показатели PUE меняются ежедневно, если не ежечасно.
• Наконец, продолжаются дискуссии относительно эффективности охладителей с водяным охлаждением и охладителей с воздушным охлаждением. В каждом применении есть несколько вариантов "естественного охлаждения" или "экономайзера" для снижения PUE. В данном примере при принятии бизнес-решения о совокупной стоимости владения/окупаемости инвестиций необходимо задать себе следующий вопрос: Какова стоимость обслуживания системы водоочистки и водоподготовки для решения с водяным охлаждением? Следует понимать, что для типичного центра обработки данных мощностью 2 мегаватта с водяным охлаждением колонн потребуется от 50 до 60 000 галлонов воды в день.
Используйте PUE для достижения общих бизнес-целей, но будьте осторожны. Постарайтесь не попасть в ловушку, ошибочно используя формулу расчета для оправдания общего бюджета на капитальные и эксплуатационные расходы.
Существует множество способов проиллюстрировать и понять распределение баланса между показателями PUE, ROI и TCO. Ниже приведены три наглядных примера, представляющие просчет или недопонимание.
• Какой день использовался в качестве "критерия проектирования" для расчета? Расчеты или измерения были выполнены в "идеальный день"? Или расчет был основан на среднегодовом значении?
• Был ли расчет основан на полностью или частично загруженном рабочем состоянии центра обработки данных? Все кривые эффективности оборудования изменяются в зависимости от профилей нагрузки. В реальных рабочих условиях показатели PUE меняются ежедневно, если не ежечасно.
• Наконец, продолжаются дискуссии относительно эффективности охладителей с водяным охлаждением и охладителей с воздушным охлаждением. В каждом применении есть несколько вариантов "естественного охлаждения" или "экономайзера" для снижения PUE. В данном примере при принятии бизнес-решения о совокупной стоимости владения/окупаемости инвестиций необходимо задать себе следующий вопрос: Какова стоимость обслуживания системы водоочистки и водоподготовки для решения с водяным охлаждением? Следует понимать, что для типичного центра обработки данных мощностью 2 мегаватта с водяным охлаждением колонн потребуется от 50 до 60 000 галлонов воды в день.
Используйте PUE для достижения общих бизнес-целей, но будьте осторожны. Постарайтесь не попасть в ловушку, ошибочно используя формулу расчета для оправдания общего бюджета на капитальные и эксплуатационные расходы.
Ошибка 8: Непонимание сертификата LEED
На сегодняшний день Совет США по экологическому строительству (USGBC) не установил конкретных критериев LEED для центров обработки данных. Однако сертификацию можно получить с помощью контрольного списка для коммерческих помещений. Присутствует три неправильных действия:
• Отсутствие базового понимания критериев квалификации. Это можно исправить, ознакомившись с вышеуказанным документом.
• Решение получить сертификат LEED, принятое задним числом. Получение сертификата LEED начинается с концепции проектирования и заканчивается официальной сертификацией после завершения проекта. В начале процесса планирования следует привлечь квалифицированного специалиста LEED или консалтинговую фирму.
Возникнут расходы, связанные с получением сертификации. Несоблюдение этих требований повлияет на совокупную стоимость владения и процессы планирования бизнес-решений
• Отсутствие базового понимания критериев квалификации. Это можно исправить, ознакомившись с вышеуказанным документом.
• Решение получить сертификат LEED, принятое задним числом. Получение сертификата LEED начинается с концепции проектирования и заканчивается официальной сертификацией после завершения проекта. В начале процесса планирования следует привлечь квалифицированного специалиста LEED или консалтинговую фирму.
Возникнут расходы, связанные с получением сертификации. Несоблюдение этих требований повлияет на совокупную стоимость владения и процессы планирования бизнес-решений
Ошибка 9: Слишком сложные конструкции
Как уже говорилось ранее, чем проще — тем лучше. Независимо от выбранного целевого уровня существует десятки способов проектирования эффективной системы. Слишком часто цели по резервированию приводят к чрезмерной сложности. Добавьте несколько подходов к построению модульной системы, и все усложнится очень быстро.
При работе внутри компании или с выбранным консультантом главной целью должна быть простота. Почему?
• Сложность часто означает большее количество оборудования и компонентов. Больше деталей означает больше точек отказа.
• Человеческий фактор. Статистика отличается, но остается постоянной. Большинство сбоев в центрах обработки данных связано с человеческими ошибками. Сложные системы повышают операционные риски.
• Стоимость. Сборка простых систем обходится дешевле.
• Расходы на эксплуатацию и техническое обслуживание. Опять же, сложность часто означает увеличение количества оборудования и компонентов. Дополнительные затраты на эксплуатацию и техническое обслуживание могут возрастать экспоненциально.
• Проектируйте с учетом конечных результатов. Многие проекты хорошо выглядят на бумаге. Вам или вашему консультанту легко обосновать выбранную конфигурацию и итоговый потенциал безотказной работы. Однако если проект не учитывает фактор "ремонтопригодности" при эксплуатации или обслуживании, это может отрицательно сказаться на работоспособности системы и безопасности персонала.
Хотя многие проекты, сборки и расширения центров обработки данных заканчиваются неудачей, ваш не должен быть в их числе. Избегая 9 главных ошибок, описанных в этой статье, вы будете уверенно двигаться к успеху. В заключение:
1. Начните с подхода к совокупной стоимости владения
• Оцените профиль рисков в соответствии с профилем деловых расходов
• Создайте модель, которая включает капитальные, эксплуатационные расходы и затраты на электроэнергию
2. Определите критерии проектирования и характеристики производительности
• Основывайте эти критерии на профиле рисков и бизнес-целях
• Позвольте этим критериям действительно определять проект, включая уровень Tier, местоположение и план пространства, а не наоборот
3. Проектируйте с учетом простоты и гибкости
• Используйте конструкцию, соответствующую вашим требованиям ко времени безотказной работы, но также позволяющую снизить расходы на строительство и эксплуатацию — ключевым фактором является простота.
• Предусмотрите возможность внепланового расширения за счет обеспечения гибкости конструкции
4. Если показатели PUE и LEED являются частью ваших критериев, изучите распространенные недопонимания и связанные с ними расходы.
Надлежащее планирование с использованием подхода, основанного на совокупной стоимости владения, позволяет создать центр обработки данных, отвечающий задачам вашей организации в отношении производительности и потребностям бизнеса сегодня и в будущем.
При работе внутри компании или с выбранным консультантом главной целью должна быть простота. Почему?
• Сложность часто означает большее количество оборудования и компонентов. Больше деталей означает больше точек отказа.
• Человеческий фактор. Статистика отличается, но остается постоянной. Большинство сбоев в центрах обработки данных связано с человеческими ошибками. Сложные системы повышают операционные риски.
• Стоимость. Сборка простых систем обходится дешевле.
• Расходы на эксплуатацию и техническое обслуживание. Опять же, сложность часто означает увеличение количества оборудования и компонентов. Дополнительные затраты на эксплуатацию и техническое обслуживание могут возрастать экспоненциально.
• Проектируйте с учетом конечных результатов. Многие проекты хорошо выглядят на бумаге. Вам или вашему консультанту легко обосновать выбранную конфигурацию и итоговый потенциал безотказной работы. Однако если проект не учитывает фактор "ремонтопригодности" при эксплуатации или обслуживании, это может отрицательно сказаться на работоспособности системы и безопасности персонала.
Хотя многие проекты, сборки и расширения центров обработки данных заканчиваются неудачей, ваш не должен быть в их числе. Избегая 9 главных ошибок, описанных в этой статье, вы будете уверенно двигаться к успеху. В заключение:
1. Начните с подхода к совокупной стоимости владения
• Оцените профиль рисков в соответствии с профилем деловых расходов
• Создайте модель, которая включает капитальные, эксплуатационные расходы и затраты на электроэнергию
2. Определите критерии проектирования и характеристики производительности
• Основывайте эти критерии на профиле рисков и бизнес-целях
• Позвольте этим критериям действительно определять проект, включая уровень Tier, местоположение и план пространства, а не наоборот
3. Проектируйте с учетом простоты и гибкости
• Используйте конструкцию, соответствующую вашим требованиям ко времени безотказной работы, но также позволяющую снизить расходы на строительство и эксплуатацию — ключевым фактором является простота.
• Предусмотрите возможность внепланового расширения за счет обеспечения гибкости конструкции
4. Если показатели PUE и LEED являются частью ваших критериев, изучите распространенные недопонимания и связанные с ними расходы.
Надлежащее планирование с использованием подхода, основанного на совокупной стоимости владения, позволяет создать центр обработки данных, отвечающий задачам вашей организации в отношении производительности и потребностям бизнеса сегодня и в будущем.
Дополнительные ресурсы
Контакты
Об авторах
Майк М. Хейган присоединился к Schneider Electric в 2011 году вскоре после приобретения Lee Technologies. До этого Хейган работал в компании Lee Technologies с 1988 года.
Являясь 25-летним ветераном отрасли, Хейган реализует ориентированный на клиента подход к продажам и маркетингу, который направлен на разработку бизнес-стратегий с использованием правильных тактических решений. Он заинтересован в планировании центров обработки данных на основе ключевых принципов бизнеса, таких как получение конкурентного преимущества, снижение затрат на эксплуатацию, сохранение капитала, расширение рынков и увеличение прибыли.
Хейган является автором многочисленных информационных документов и статей для отраслевых периодических изданий и часто выступает на отраслевых мероприятиях, включая Tier1, 7x24 Exchange, Data Center Dynamics, AFCOM и CoreNet Global. Прежде чем присоединиться к компании Lee Technologies Майк Хейган занимал старшие должности в отделах управления и продаж в Liebert, Hitachi, SunGard и Danaher Corporation. Он получил степень бакалавра в области машиностроения в Университете Майами в Оксфорде, штат Огайо.
Джон Луски является директором электротехнического проектирования в отделе проектирования/строительства сервисной группы компании Lee Technologies. В его обязанности входит оценка и проектирование критически важных систем энергоснабжения, связанных со средами центров обработки данных.
Имея более 14 лет опыта в проектировании, строительстве, интеграции и установке промышленных систем управления и критических систем энергоснабжения, Джон продолжает ломать стереотипы в инженерной области. Его обширный опыт в управлении процессами и промышленной автоматизации дал ему глубокое понимание различных систем управления и взаимодействия, которое присутствует в системах с высокой избыточностью, охватывающих несколько дисциплин в критически важной среде. Джон разработал ряд чрезвычайно надежных, но экономичных решений, которые позволяют расширять системы с использованием модулей по мере увеличения нагрузки.
Глубокое понимание Джоном процесса строительства и технического обслуживания в средах центров обработки данных позволяет свести к минимуму проблемы на этапе строительства и упростить обслуживание в будущем. Он тесно сотрудничает с заказчиками для определения их особых требований, не пытаясь вписать их потребности в существующие проекты. Кроме того, он регулярно работает с заказчиками, чтобы помочь им понять принципы моделирования совокупной стоимости владения, выбора площадки и инициатив PUE/LEED.
Туан Хоанг, профессиональный инженер, является ведущим инженером компании Lee Technologies, возглавляя проектно-техническую группу компании по разработке решений для центров обработки данных. Обязанности Туана включают оценку и проектирование различных критически важных систем ОВКВ, включая компьютерные системы кондиционирования воздуха, охладители, градирни и увлажнение. До прихода в Lee Technologies в 2005 году Туан проектировал жизненно важные системы охлаждения и вентиляции для авианосцев ВМС США с компанией Northrop Grumman, а также фирмой MEP.
Являясь 10-летним ветераном в области критически важных систем охлаждения, Туан предлагает своим заказчикам различные подходы к проектированию важных систем для центров обработки данных. Его опыт охватывает оценку производственных объектов, расчеты прогнозируемого роста и решения для обеспечения плавного перехода между этапами разработки.
Скотт Уолш, профессиональный инженер, аккредитованный инженер LEED, является инженером подразделения проектирования/строительства сервисной группы компании Lee Technologies. В текущие обязанности Скотта входят полевые изыскания и проверки; выбор и спецификация оборудования; расчет нагрузки; проверка проектной документации на соответствие нормативам; составление чертежей; подготовка рабочей строительной документации; и координация на местах.
Благодаря более чем 7-летнему опыту работы в сфере центров обработки данных Скотт получил знания в области проектирования механических систем, анализа требований, планирования проектов в рамках инициативы LEED, стратегического планирования проектов, инженерной разработки и управления проектами ЦОД. Он имеет специализированный опыт использования PUE для разработки широкого спектра проектов центров обработки данных по инициативе LEED.
Являясь 25-летним ветераном отрасли, Хейган реализует ориентированный на клиента подход к продажам и маркетингу, который направлен на разработку бизнес-стратегий с использованием правильных тактических решений. Он заинтересован в планировании центров обработки данных на основе ключевых принципов бизнеса, таких как получение конкурентного преимущества, снижение затрат на эксплуатацию, сохранение капитала, расширение рынков и увеличение прибыли.
Хейган является автором многочисленных информационных документов и статей для отраслевых периодических изданий и часто выступает на отраслевых мероприятиях, включая Tier1, 7x24 Exchange, Data Center Dynamics, AFCOM и CoreNet Global. Прежде чем присоединиться к компании Lee Technologies Майк Хейган занимал старшие должности в отделах управления и продаж в Liebert, Hitachi, SunGard и Danaher Corporation. Он получил степень бакалавра в области машиностроения в Университете Майами в Оксфорде, штат Огайо.
Джон Луски является директором электротехнического проектирования в отделе проектирования/строительства сервисной группы компании Lee Technologies. В его обязанности входит оценка и проектирование критически важных систем энергоснабжения, связанных со средами центров обработки данных.
Имея более 14 лет опыта в проектировании, строительстве, интеграции и установке промышленных систем управления и критических систем энергоснабжения, Джон продолжает ломать стереотипы в инженерной области. Его обширный опыт в управлении процессами и промышленной автоматизации дал ему глубокое понимание различных систем управления и взаимодействия, которое присутствует в системах с высокой избыточностью, охватывающих несколько дисциплин в критически важной среде. Джон разработал ряд чрезвычайно надежных, но экономичных решений, которые позволяют расширять системы с использованием модулей по мере увеличения нагрузки.
Глубокое понимание Джоном процесса строительства и технического обслуживания в средах центров обработки данных позволяет свести к минимуму проблемы на этапе строительства и упростить обслуживание в будущем. Он тесно сотрудничает с заказчиками для определения их особых требований, не пытаясь вписать их потребности в существующие проекты. Кроме того, он регулярно работает с заказчиками, чтобы помочь им понять принципы моделирования совокупной стоимости владения, выбора площадки и инициатив PUE/LEED.
Туан Хоанг, профессиональный инженер, является ведущим инженером компании Lee Technologies, возглавляя проектно-техническую группу компании по разработке решений для центров обработки данных. Обязанности Туана включают оценку и проектирование различных критически важных систем ОВКВ, включая компьютерные системы кондиционирования воздуха, охладители, градирни и увлажнение. До прихода в Lee Technologies в 2005 году Туан проектировал жизненно важные системы охлаждения и вентиляции для авианосцев ВМС США с компанией Northrop Grumman, а также фирмой MEP.
Являясь 10-летним ветераном в области критически важных систем охлаждения, Туан предлагает своим заказчикам различные подходы к проектированию важных систем для центров обработки данных. Его опыт охватывает оценку производственных объектов, расчеты прогнозируемого роста и решения для обеспечения плавного перехода между этапами разработки.
Скотт Уолш, профессиональный инженер, аккредитованный инженер LEED, является инженером подразделения проектирования/строительства сервисной группы компании Lee Technologies. В текущие обязанности Скотта входят полевые изыскания и проверки; выбор и спецификация оборудования; расчет нагрузки; проверка проектной документации на соответствие нормативам; составление чертежей; подготовка рабочей строительной документации; и координация на местах.
Благодаря более чем 7-летнему опыту работы в сфере центров обработки данных Скотт получил знания в области проектирования механических систем, анализа требований, планирования проектов в рамках инициативы LEED, стратегического планирования проектов, инженерной разработки и управления проектами ЦОД. Он имеет специализированный опыт использования PUE для разработки широкого спектра проектов центров обработки данных по инициативе LEED.