Oracle Grid на платформах Sun

На самой первой презентации технологии Oracle Grid, проходившей в 2003 г., глава корпорации Oracle Ларри Эллисон, выразил уверенность в том, что это событие знаменует крутой поворот в развитии ИТ-индустрии. С тех пор технология Oracle Grid развивалась, получая всё больше сторонников среди заказчиков. Одновременно с нею огромную популярность обрела идея виртуализации, которая на первый взгляд противостоит подходу Oracle Grid, базирующемуся на кластеризации серверов: если виртуализация предполагает исполнение нескольких приложений в изолированных разделах одного сервера, то кластеризация, напротив, обеспечивает одному приложению прозрачный доступ к ресурсам множества серверов. Первый подход ориентирован на достаточно мощные многопроцессорные машины, которые способны нести на себе нагрузку множества разных приложений. При этом ресурсы сервера с целью наиболее оптимального их использования могут оперативно перераспределяться между приложениями. В случае Grid подобная оптимизация достигается путем оперативного формирования кластерных пулов (как правило, из недорогих серверов стандартной архитектуры) в ответ на меняющиеся потребности предприятия. На самом деле указанные два подхода не конкурируют, а дополняют друг друга. Об этом свидетельствуют, в частности, варианты решений Oracle Grid на базе серверов Sun Microsystems.

Напомним, что архитектура Oracle Enterprise Grid основана на кластеризации серверных ресурсов на трех уровнях: системы хранения (Storage Grid) — с помощью ПО Automatic Storage Manager (ASM), сервера БД (Database Grid) — на базе Real Application Clusters (RAC) и промежуточного слоя (Application Server Grid) — на основе Application Server. Единый пул таких ресурсов динамически перераспределяется в соответствии с требованиями бизнеса между различными приложениями с помощью Oracle Enterprise Manager Grid Control, обеспечивающего управление всей инфраструктурой Grid.

Такой подход открывает дорогу к динамическому выделению и перераспределению доступных серверных ресурсов, повышению масштабируемости информационной среды, в том числе и облачной. Представим, к примеру, что один кластер поддерживает работу интернет-магазина, а другой — хранилище данных для аналитического приложения. В дни предпраздничной торговли, когда нагрузка на первый сильно возрастает, к нему можно подключить серверы, выводимые из состава второго. После праздника торговля замирает, но наступает время аналитиков и повышается нагрузка на хранилище данных. Теперь уже серверы из первого кластера передаются второму. Одновременно с этим решается и задача повышения отказоустойчивости, поскольку отдельные узлы кластера могут находиться в “горячем” резерве. Определенным ограничением архитектуры Oracle Enterprise Grid является ее моноплатформенность: в состав кластера могут входить только однородные в смысле программно-аппаратной платформы узлы. Впрочем, при этом не возбраняется создавать отдельные Grid-пулы для каждой такой платформы.

В России одной из первых среди начавших заниматься технологией Oracle Grid была компания Открытые Технологии. Она же, кстати, является одним из старейших и ведущих партнеров Sun Microsystems. По словам системного архитектора отдела ЦОД Открытых Технологий Виктора Липина, первые шаги в этом направлении компания сделала до 2003 г., после выпуска версии Oracle Database 9i, в которой впервые была реализована технология RAC. Вскоре после того, как свет увидела СУБД Oracle Database 10g, лежащая в основе Oracle Enterprise Grid, Открытые Технологии получили от Oracle статус центра компетенции по кластерным технологиям, которым обладают до сих пор. Сегодня компании также присвоены статусы Premier (Enterprise) Partner, Datacenter Accredited Partner и System Support Help Desk (Sun Service Manager) от Sun Microsystems и Certified Advantage Partner от Oracle.

Насколько широко данная архитектура используется российскими заказчиками? “На мой взгляд, не следует говорить об Oracle Grid как о какой-то особой технологии или наборе продуктов, подлежащих внедрению, — убежден Виктор Липин. — Скорее, подобную схему следует иметь в виду при проектировании ИС, предусматривая готовность к построению среды Grid. Наш опыт показывает, что если в организации эксплуатируется Oracle Database 10g и количество баз данных более пяти, то инструментарий Oracle Enterprise Manager Grid Control, скорее всего, там используется. Целью, как правило, являются решение текущих задач по управлению существующими приложениями и мониторинг их функционирования. В первую очередь интерес к данной технологии проявляют компании из отраслей, наиболее зависящих от ИТ-сервисов, — телекоммуникационной и финансовой. Хотел бы обратить внимание на уникальные возможности применения в Grid-архитектурах Oracle всех линеек серверов Sun. Заметным их достоинством является всё более широкое использование высокоскоростных флэш-накопителей. При обработке больших объемов данных, характерных для Grid, на первое место выходят задачи оптимизации ввода-вывода.

Sun применяет SSD-диски и как замену традиционных FC/SAS-дисков, и как ресурс кэширования ввода-вывода. При этом предлагаются решения не только на уровне дисковых массивов (Flash Accelerator чтения и записи), но и на уровне непосредственно серверов (Sun Flash Accelerator F20 PCIe Card)”.

Sun выпускает как серверы стандартной архитектуры — Sun Fire x64 под управлением ОС Solaris, OpenSolaris, Linux и Windows, поддерживающие все классические функции Oracle Grid, — так и системы Sun SPARC Enterprise на базе RISC-процессоров UltraSPARC и SPARC64. Все серверы Sun предоставляют возможности виртуализации, что создает дополнительные преимущества для функционирования Oracle Grid. Их также объединяет то, что они могут работать под управлением ОС Solaris. В Solaris 10 реализована виртуализация на основе изолированных контейнеров (Solaris 10 Containers), когда каждому приложению (или группе), работающему на сервере c одним экземпляром ОС, выделяется отдельный контейнер. При этом сбой одного приложения не приводит к нарушению работы остальных. Если же взять несколько подобных серверов и объединить их в кластер, то RAC-конфигурации СУБД Oracle можно составлять из контейнеров, функционирующих на разных узлах кластера. Более того, на каждом узле можно развернуть несколько серверов БД (в отдельных контейнерах), обслуживающих каждый свое приложение, а затем объединить их в своеобразные виртуализованные кластеры RAC. Это сразу же существенно повышает отказоустойчивость и в то же время дает дополнительные возможности балансировки нагрузки. Если нагрузка на какое-либо приложение увеличивается, то наряду с включением в кластер нового узла (классический Oracle Grid) можно передавать ресурсы перегруженному контейнеру от менее занятых “собратьев” в рамках одного узла. Такое гибкое перераспределение ресурсов позволяет гораздо тоньше оптимизировать использование корпоративных информационных активов.

Более широкие возможности открываются на тех предприятиях, что уже приобрели новые серверы семейства Sun SPARC Enterprise T5xx0 с многоядерными процессорами Sun UltraSPARC T1, T2 или T2 Plus. Эти возможности связаны с реализованной в указанных процессорах технологией многопоточности CoolThreads, позволяющей формировать логические домены LDoms с высокой степенью дискретности: на аппаратном уровне потоков процессора, а не целых процессоров. К примеру, в случае UltraSPARC T2 таких потоков, исполняющих роль логических процессоров, будет 64 на каждый физический кристалл. В отношении виртуализации домены LDoms являются своеобразным аналогом динамических доменов (Dynamic Domains), и в каждом из них исполняется собственная копия ОС Solaris. В нескольких таких доменах, независимо от того, где они расположены — на одном физическом сервере или на разных, может запускаться кластерная RAC-конфигурация СУБД Oracle Database. В случае необходимости перераспределения нагрузки между экземплярами СУБД Oracle, принадлежащими разным приложениям, управлять логическими доменами и выделяемыми им ресурсами в данном случае можно гораздо рациональнее.

Отметим, что возможность развертывания кластера RAC, состоящего из узлов LDoms, расположенных на одном физическом сервере, очень полезна на этапах разработки и тестирования кластерных приложений, поскольку не требует наличия у разработчиков соответствующего числа довольно дорогих машин. Если же продуктивная конфигурация такого рода развертывается на нескольких физических серверах, мы получаем преимущества оптимального использования серверных ресурсов и отказоустойчивости.

И, наконец, самую высокую степень изоляции виртуальных сред друг от друга обеспечивают серверы флагманской серии Sun Enterprise M3000-M9000, позволяющие создавать электрически изолированные друг от друга динамические домены на уровне системных плат. Такие домены также могут включаться в кластерные RAC-конфигурации, поддерживающие наиболее ответственные и критически важные для бизнеса прикладные системы.

В целом же сочетание технологий Grid от Oracle и виртуализации от Sun дает беспрецедентно гибкие возможности управления серверными ресурсами предприятия, оптимального использования вычислительных мощностей, а также рациональной эксплуатации помещений дата-центров, экономии электроэнергии и снижения затрат на поддержку ИТ-инфраструктуры.

Предыдущая новость:
Резервное копирование виртуальных сред Следующая новость:
Новые возможности анализа трафика