 |
18 февраля 2025 года,
Алматы, The Rixos Hotel Almaty |
 |
18.12.2014 Автор: Александр ГЕРАСИМОВ  Аппаратным платформам для бизнес-критичных приложений предстоит кардинальная трансформация. Ее сделает неизбежной появление «тяжелых» ERP-систем и другого бизнес-критичного ПО в формате облачных сервисов, о котором, как и о создании в России соответствующей инфраструктуры, заявили в 2014 г. ведущие вендоры. Корпоративный ЦОД и ЦОД облачного провайдера. В чем разница? До недавнего времени не только в России, но и в других странах бизнес-критичные приложения в формате облачных и онлайн-сервисов не предоставлялись. Облачные и интернет-провайдеры ограничивались в основном массовыми сервисами, преимущественно бесплатными, от которых потребитель не ждал и не требовал высокой доступности, безопасности и пр. (рис. 1). А все критичные приложения были инсталлированы исключительно в корпоративных дата-центрах.
Подчеркнем, что принципы построения и оснащения корпоративных дата-центров традиционных предприятий и дата-центров провайдеров облачных и онлайн-сервисов различаются кардинально (см. таблицу и рис. 2). Наряду с коммерчески обоснованной стоимостью строительства и эксплуатации для облачных провайдеров чрезвычайно важно быстрое и гибкое масштабирование как приложений, так и аппаратной платформы. Поэтому они, как правило, используют обычные серверы стандартной архитектуры, причем зачастую нижнего ценового диапазона, и преимущественно внутрисерверные диски, но с развитым слоем виртуализации. Для корпоративного дата-центра экономические характеристики и масштабируемость – на втором плане. На первом – высокая доступность аппаратной платформы для запущенных в ней приложений и отказоустойчивость системы в целом. Отсюда – установка дорогостоящих серверов нестандартной архитектуры, в том числе мейнфреймов, систем охлаждения, работающих с большим запасом при температуре 20–22°С против 28°С у облачных провайдеров и пр. В сумме это существенно повышает стоимость как оснащения корпоративного дата-центра полезной нагрузкой, так и его эксплуатации, но при этом дает уверенность в высокой доступности и отказоустойчивости. Аналогичным образом оснащены и коммерческие дата-центры, работающие по модели colocation, поскольку они используются, как правило, в качестве резервных площадок корпоративных ЦОДов.
Бизнес-критичная нагрузка и ее аппаратная платформа Для бизнес-критичных приложений, несмотря на успехи технологий виртуализации, наиболее распространенной ситуацией до сих пор является жесткая привязка программного приложения к конкретной аппаратной платформе. Так, серверы баз данных больших ERP- и других транзакционных систем (биллинг, процессинг и т.п.) «живут» на объединенных в кластеры серверах нестандартной архитектуры под управлением ОС UNIX и системах хранения данных (СХД) архитектуры SAN (Storage Area Network). Масштабирование и оптимизация таких платформ крайне затруднены. В результате средняя загрузка дорогостоящих нестандартных серверов зачастую не превышает 10–15%, а при попытках ее повысить за счет «урезания» аппаратной части появляются проблемы на пиках нагрузки, которые до недавнего времени не могли быть решены за счет аренды внешних мощностей по модели IaaS или PaaS. Основная причина такой ситуации – монолитность баз данных большинства бизнес-критичных систем. Их инсталляция была возможна только на один физический сервер, который должен был обладать высокой доступностью и отказоустойчивостью. При этом сложность и затратность масштабирования подобных систем компенсировалась плавным и предсказуемым ростом потребностей в вычислительных мощностях со стороны прикладного уровня, которые четко коррелировали с ростом бизнеса компании-заказчика. Еще один недостаток серверов нестандартной архитектуры – высокие начальные инвестиции – нивелировался значительными, исчислявшимися десятками миллионов долларов в год и более, ИТ-бюджетами предприятий и организаций, которые выступали основными потребителями этого оборудования в России. Кроме того, в начальный период формирования российского рынка корпоративных приложений (1997–2007 гг.) серверы нестандартной архитектуры обладали существенно большими возможностями гибкого и, как следствие, эффективного использования их ресурсов, нежели серверы стандартной архитектуры. Формированию жесткой связки «тяжелых» корпоративных приложений и серверов нестандартной архитектуры способствовали также и разработчики приложений, оптимизировавшие их для работы именно под управлением Unix-подобных проприетарных ОС, таких, как IBM AIX, Sun Solaris и HP-UX.Еще более жесткая взаимосвязь аппаратной платформы и приложения характерна для СХД, точнее, для типа хранимых данных и используемого оборудования. Так, внешние СХД с подключением NAS (Network Attached Storage) задействуются в основном как файловые хранилища слабоструктурированных данных, а внешние СХД с подключением SAN – для хранения блочных данных больших БД. И только внутрисерверные диски используются для хранения информации обоих типов. Однако поскольку без соответствующих средств виртуализации невозможно осуществлять распределение баз данных между внутренними СХД нескольких физических серверов, сфера применения внутрисерверных СХД ограничивается базами данных относительно небольшого размера. Для больших баз данных «тяжелых» транзакционных систем используются внешние СХД SAN, а для хранения больших объемов слабоструктурированных данных – внешние файловые СХД NAS. Но такой подход, терпимый для традиционного предприятия, совершенно неприемлем для облачного провайдера. Переход облачных провайдеров к предоставлению бизнес-критичных сервисов требует совместить эти подходы в одном ЦОДе. От облачного дата-центра требуется взять высокую экономическую эффективность и практически неограниченную масштабируемость и гибкость, а от традиционного корпоративного – высокую доступность и отказоустойчивость. Как совместить два в одном Технологическая возможность решения этой проблемы включает в себя три уровня. Верхний уровень – это новое поколение высокопроизводительных реляционных СУБД с возможностью их развертывания и гибкого масштабирования в облачной среде. Сегодня уже доступны новые версии СУБД для «тяжелых» приложений, допускающие их инсталляцию в облачных средах в виде так называемой контейнерной базы данных. Такая БД управляет пулом ресурсов из множественных «подключаемых баз данных» (pluggable database), каждая из которых представляет собой полноценную базу данных и может переводиться из одного контейнера в другой. А на аппаратном уровне эти контейнеры могут представлять собой множество серверов различной архитектуры, находящихся как в корпоративном дата-центре предприятия-заказчика, так и в дата-центрах провайдеров услуг IaaS/PaaS, которые, как уже отмечалось, преимущественно используют серверы стандартной архитектуры. Средний уровень такого решения – это продвинутые технологии виртуализации, которые охватывают не только серверы, но и системы хранения данных, и активное сетевое оборудование, а также позволяют создавать полноценный виртуальный контейнер – дата-центр с возможностью полностью программного управления его конфигурацией. В частности, они дают возможность на базе серверов стандартной архитектуры и внутренних систем хранения данных создать виртуальную аппаратную среду, полностью соответствующую требованиям высоконагруженных транзакционных систем, но обладающую при этом широкими возможностями масштабирования и оптимизации. Более того, через ПО класса data center infrastructure management (DCIM) этот уровень может быть увязан с инженерной инфраструктурой дата-центра, что позволяет включать в состав виртуального (программно-управляемого) ЦОДа обеспечивающие инженерные системы. На базовом, инфраструктурном уровне находится выполненная в открытой модульной идеологии аппаратная платформа, компоненты которой максимально просты, стандартизированы, дешевы и предусматривают возможность «горячей» замены.Таким образом, речь идет о конвергенции как разных видов систем одного функционального назначения, например СХД или серверов различной архитектуры, так и систем разного назначения – серверов, СХД и активного сетевого оборудования в единый вид информационно-коммуникационного оборудования, выполненного на принципах модульности и открытой архитектуры. Конвергенция достигается за счет переноса – частичного или полного – функциональности оборудования с аппаратного уровня на программный, исполняемый на серверах общего назначения. Поэтому класс такого виртуализованного оборудования уже в меньшей степени определяется «железом», что позволяет на программном уровне обеспечить приложению именно те характеристики аппаратной платформы, какие ему необходимы в конкретный момент времени. Это дает возможность реализовать на практике одну из ключевых характеристик облачного сервиса – задействовать ресурсы по мере надобности и оказывать услуги с заданным уровнем качества обслуживания. Конвергенция серверов разной архитектуры Благодаря развитию технологий виртуализации и модульности блейд-серверы стандартной архитектуры понемногу начинают использоваться и для бизнес-критичных приложений. В частности, база данных ERP-системы ОАО «МОЭК» в 2013 г. была переведена с RISC-платформы под управлением ОС HP-UX на блейд-серверы стандартной архитектуры под управлением ОС Red Hat Enterprise Linux. Но эти стандартные серверы уже не совсем стандартные. В последнее время наметилась тенденция конвергенции стандартных и нестандартных серверов, когда в серверах стандартной архитектуры применяются решения, характерные для нестандартных серверов и даже мейнфреймов. Можно предположить, что через некоторое время появится и шасси высокой плотности, позволяющее произвести замену серверного модуля стандартной архитектуры на нестандартный и наоборот.Такие модульные комплексы комбинированной архитектуры вполне могут найти свое применение в дата-центрах облачных провайдеров. Начав предоставлять «тяжелое» бизнес-ПО по модели SaaS, провайдеры могут столкнуться с ситуацией, когда даже при использовании виртуализованного конвергированного оборудования стандартной архитектуры они не смогут обеспечить необходимый заказчикам уровень качества сервиса, эквивалентный тому, который поддерживает внутренняя ИТ-служба, задействуя нестандартные сервера, установленные в собственном дата-центре. Причина в том, что производительность модуля может оказаться узким местом – несмотря на большое количество этих модулей и развитые средства виртуализации, позволяющие на основе множества относительно маломощных модулей создавать виртуальные серверы высокой производительности и доступности. Аналогичная ситуация вполне вероятна при попытке реализовать концепции SDN/NFV на уровне ядра сети с использованием серверного оборудования стандартной архитектуры. Конвергенция СХД и серверов В настоящее время на рынке серверов и систем хранения данных уже представлены решения, которые реализуют как конвергенцию различных типов внешних СХД (DAS, NAS, SAN) в единый тип внешней СХД, способной работать со всеми видами данных, так и конвергенцию внутрисерверных СХД и внешних СХД в форме Server SAN. Server SAN – это комбинированный пул серверных ресурсов и СХД прямого подключения (DAS), в котором сервер может обращаться не только к подключенным к нему дискам, но и к дискам, физически подключенным к другим серверам виртуального пула. Обмен данными осуществляется через высокоскоростные соединения, такие, как InfiniBand или Low Latency Ethernet, где когерентность управляется программным обеспечением Server SAN, которое является основным компонентом решения, определяющим его функциональные возможности и характеристики. Ключевое отличие архитектуры Server SAN от архитектуры, традиционной для высоконагруженных систем с использованием нестандартных серверов и выделенных сетей хранения данных SAN, – ее способность к практически неограниченному масштабированию и простота управления, что принципиально для провайдеров облачных сервисов. Такая архитектура наиболее приемлема для предоставления критичных для бизнеса облачных сервисов. А конвергированные внешние СХД SAN/NAS при необходимости могут использоваться как расширение внутрисерверных СХД, реализованных по технологии Server SAN. Модульность, открытая архитектура, энергетическая нейтральность Реализация модульности с различным шагом позволяет выполнять «горячую» замену или добавление модулей без останова аппаратной платформы в целом и обеспечить таким образом 100%-ную доступность полезной нагрузки дата-центра.Так, принципиальной для аппаратных платформ крупных веб- и облачных провайдеров гипермасштабируемости в сочетании с чрезвычайно высоким уровнем доступности и отказоустойчивости можно достичь только за счет еще более мелкого, чем даже в блейд-системах, деления сервера на отдельные аппаратные модули. Такие модули объединяют в себе серверную и СХД-компоненты и чрезвычайно плотно устанавливаются на шасси, в котором размещены сетевая компонента и система энергоснабжения, а самое главное – система виртуализации. С помощью этой системы на базе большого количества относительно низкопроизводительных модулей можно реализовать платформу с характеристиками серверов и СХД верхнего ценового диапазона, но обладающую возможностью быстрого и практически неограниченного масштабирования. При этом выход из строя даже нескольких модулей практически никак не сказывается на характеристиках платформы в целом, а унификация модулей и возможность «горячей» замены позволяют быстро заменить вышедшие из строя модули исправными. Как говорилось выше, в перспективе возможно появление шасси для установки модулей различной архитектуры: скажем, в платформу, в которой преимущественно стоят серверные модули стандартной архитектуры, можно будет установить модули нестандартной архитектуры. Но это еще не все. Интересные технические изменения имеют место на уровне инженерных систем. Высокая доступность – это в значительной степени стабильность электроснабжения. А она, в свою очередь, достигается только сменой парадигмы: внешние источники электропитания облачного дата-центра должны стать резервными, а основными – внутренние. Особенно это актуально для России, где более 80% площадей дата-центров сосредоточено в Москве. Сколько бы независимых вводов электроснабжения они не имели, все равно они запитаны от единой энергосистемы Москвы. Насколько она устойчива, мы все имели возможность наблюдать 25 мая 2005 г. , когда произошла крупная авария, в результате которой на несколько часов была отключена подача электроэнергии в несколько районов Москвы, Подмосковья, а также Тульской, Калужской и Рязанской областей. Задача создания энергетически нейтрального дата-центра решается как снижением энергопотребления объекта инфраструктуры, так и использованием альтернативных (с более высоким КПД, нежели у традиционных) и возобновляемых источников энергии. То есть энергоэффективность – это вопрос не столько экологичности дата-центра, сколько его высокой доступности и экономичности. Лидеры облачной индустрии добились значительных успехов в трансформации своих ЦОДов в соответствии с принципом энергетической нейтральности. Например, дата-центры корпорации Apple – одни из крупнейших в мире – уже сейчас 75% своих потребностей в электроэнергии удовлетворяют за счет возобновляемых источников, а в ближайшие годы этот показатель планируется довести до 100%. Другой лидер облачной индустрии – корпорация eBay – осенью 2013 г. запустила в эксплуатацию дата-центр, основная система энергоснабжения которого полностью выполнена на топливных элементах. А корпорация Microsoft выдвинула идею замены традиционной схемы энергоснабжения дата-центров на располагаемые непосредственно в серверных стойках компактные топливные элементы, что в сочетании с технологиями фрикулинга также позволит реализовать принцип энергетической нейтральности дата-центра. |
