В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Хорошее определение центрам обработки данных (ЦОД) дано в журнале Network World, которое я выбрал в качестве эпиграфа для данной статьи. Если не переводить дословно, ЦОД – это некий комплекс, в котором:
Таким образом, ЦОД для нас – это в первую очередь совокупность информационных систем, интегрированных как друг с другом, так и с базовой инфраструктурой, специально созданной для этих систем.
Работа современных компаний всецело зависит от функционирования различных информационных систем. В такой ситуации к информационным системам целесообразно относиться как к одному из ключевых бизнес-процессов или направлений, присутствующих в компании. IТ-системы – это инструмент для решения задач бизнеса. Именно они способны обеспечить значительное конкурентное преимущество за счет оперативного обеспечения функционирования основных и вспомогательных бизнес-процессов.
Создавая инфраструктуру для функционирования информационных систем, следует учитывать непосредственные потребности бизнеса, которые должны быть четко сформулированы и определены как дискретные величины в терминах, понятных функциональным заказчикам систем (бизнес-пользователям). Позднее для каждой из информационных систем приглашенные консультанты, возможно с помощью поставщика прикладного ПО, смогут трансформировать эти требования в величины, характеризующие параметры производительности вычислительного комплекса, системы хранения данных и иных компонентов инфраструктуры. Также для эффективного функционирования любой информационной системы бизнес должен определить требования к уровню доступности системы. Одни системы, из-за отсутствия которых компания не может предоставлять услуги или вообще выполнять основной вид своей деятельности (так называемые mission critical systems), требуют особого отношения со стороны IТ-службы и должны быть доступны 99,999% времени. Для систем, без которых компания может продолжать ведение бизнеса, но, к примеру, не может развиваться, традиционно предъявляются требования более низкие – 99,9% доступности. Определение требований к доступности систем – это отдельное упражнение, которое выполняется в составе BIA (Business Impact Analysis). И только при таком подходе сформированные требования можно считать корректными.
Довольно часто компании пренебрегают необходимостью проведения такой работы и формулируют неадекватно высокие требования, что приводит к неоправданному повышению затрат на построение IТ-инфраструктуры. Не менее важными являются характеристики, сформулированные бизнес-пользователями и не имеющие непосредственного отношения к производительности систем. Однако именно они зачастую определяют архитектуру. Например, требования по срокам предоставления какого-либо нового сервиса, требования по обеспечению гибкости при дальнейшем наращивании производительности систем и иные требования, влияющие на выбор архитектуры.
При планировании архитектуры необходимо понимать, что системы разнородны, нагрузка на них непостоянна и это приводит к неэффективной утилизации оборудования. Для того чтобы этого избежать, необходимо использовать различные подходы к построению не только каждой из систем, но и их отдельных частей. Таким образом, в составе нового ЦОД найдется место как для высокопроизводительных серверов уровня Enterprise для решения задач, не позволяющих использовать распределенные вычисления, так и для лезвий, объединенных в кластеры и использующихся для функционирования виртуальных серверов. Последние теперь принято называть облаками. Для облачных структур очень полезными окажутся комплексные программные продукты вендеров, нацеленные на повышение эффективности IТ-инфраструктуры.
Также выбор платформы для реализации той или иной критичной бизнес-системы напрямую зависит от требований к уровню доступности, предъявленных со стороны бизнеса.
Для того чтобы обеспечить надежное функционирование ЦОД, необходимо выбрать и внедрить набор решений, которые позволят поддерживать процессы, связанные с эксплуатацией. Все подобные решения базируются на принятых вендорами принципах, основанных на методологии ITIL. Обычно это совокупность систем, включающих в себя Service Desk (Incident Management), CMDB (Configuration Management DataBase), системы для управления изменениями, системы мониторинга. Очевидно, что для наиболее эффективного функционирования эти системы должны быть тесно интегрированы. Важно сделать стратегический выбор вендора, на продуктах которого будут построены все эти системы. В дальнейшем наличие этих систем также позволит поддерживать процесс планирования мощностей (capacity planning). Этот процесс является циклическим, и его требуется активировать с минимальной периодичностью раз в год.
Сколько же это все стоит? Как ранее было сказано, выбор платформы напрямую зависит от требований, предъявляемых со стороны бизнеса к выполнению тех или иных задач. Это, в свою очередь, порождает существенную разницу в стоимости тех или иных решений. Решения на high-end-платформах могут быть на порядок дороже систем, созданных на базе commodity-серверов и Midrange дисковых массивов. При этом стоимость прикладного ПО этих же самых систем значительно выше стоимости оборудования. Практика показывает, что доля стоимости оборудования в составе Enterprise-систем составляет 10–15%, примерно такой же процент от стоимости инфраструктуры составляет стоимость системного программного обеспечения, являющегося, по сути, наложенным средством обеспечения высокой доступности или "еще одним слоем" для средств виртуализации. И вот эти самые 10–15% стоимости информационной системы в случае излишней экономии могут привести к тому, что вся информационная система окажется неработоспособной. Не хочется делать из этого каких-либо выводов, но совет один: "Не экономьте на спичках".
В ситуации, когда стоимость системы оказывается неоправданно высокой, необходимо в первую очередь провести ревизию требований, которые были предъявлены к системам. Возможно, эти требования были определены ошибочно, и их необходимо пересмотреть или изменить подход к управлению рисками, которые до этого планировалось закрыть избыточной инфраструктурой.
На основании решений, выбранных для реализации систем, которые будут входить в ЦОД, необходимо сформулировать требования к инженерной инфраструктуре ЦОД. В них войдут:
Все это позволит грамотно и в соответствии с требованиями бизнеса и стандартов подойти к планированию дата-центра.
В заключение хотелось бы остановиться на сервисном обслуживании как очередном этапе при комплексном подходе к строительству ЦОД. Уровень доступности и безотказности в предоставлении IТ-сервисов зависит не только от архитектуры самих информационных систем, но и от работоспособности инженерных систем серверной (или дата-центра), в которых размещено оборудование. Есть два аспекта в обеспечении доступности инженерного сервиса – это вопросы архитектуры (построения) инженерных подсистем и вопросы сервисного обслуживания.
Можно рекомендовать руководителям предприятий и IТ-подразделений обратить особое внимание на периодичность и глубину сервисного обслуживания. С одной стороны, выход из строя системы кондиционирования вызовет останов серверной или дата-центра в течение нескольких минут, с другой – организация регулярного осмотра, замена неисправных компонентов, внедрение систем дистанционного мониторинга могут в комплексе нивелировать недостатки и слабые места, возможно, допущенные на этапах проектирования и строительства.
Грамотно построенный уровень соглашений о сервисном обслуживании (SLA) обеспечит, с одной стороны, четкое выполнение требований бизнеса с точки зрения доступности, прозрачности предоставляемых услуг, с другой – позволит избежать ненужных затрат на несогласованное обеспечение бесперебойности работы инженерных систем. Более того, сервисное обслуживание среднего дата-центра за год стоит существенно меньше возможных потерь, связанных с простоем и/или выходом из строя IТ-оборудования и нарушением работоспособности бизнес-приложений.
Опубликовано: Журнал "Технологии и средства связи" #2, 2011
Посещений: 5510
Статьи по теме
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
