IBM DataPower — это программно-аппаратный комплекс, преднастроенный для интеграции информационных систем.
Тендерная процедура прошла в формате запроса котировок с ограниченным количеством участников — среди официальных дистрибьюторов вендора в России. В банке ранее сообщали CNews, что закупки у подобных поставщиков, которые берут на себя функции логистики и таможенного оформления, позволяют оптимизировать стоимость оборудования за счет исключения из цепочки поставок лишних звеньев и обеспечить прозрачность ценообразования.
Такая схема работы, как считают в Сбербанке, дает достаточное объяснение невысокому относительному снижению стоимости подобных лотов, так как оно достигается исключительно за счет уменьшения прибыльности дистрибьютора.
По итогам конкурса предусмотрено заключение так называемого генерального соглашения на 1 год. В этот период банк (включая все его российские филиалы) по мере необходимости сможет размещать отдельные заказы на приобретение IBM DataPower по фиксированным ценам. При этом важно понимать, что такой формат договоренностей не обязывает Сбербанк выкупать все оборудование в полном объеме максимальной стоимости соглашения.
Гарантийные обязательства поставщика также рассчитаны на 1 год, однако этот срок станет исчисляться с момента подписания акта сдачи-приемки продукции.
Программа расширенного сопровождения поставляемого оборудования подразумевает устранение неисправностей в течение 6 часов с момента поступления соответствующих запросов. Исполнитель должен располагать достаточным резервом запчастей и материалов и принимать участие в работах по интеграции обслуживаемой продукции с оборудованием и ПО третьих фирм.
В состав продукции входит предустановленное системное программное обеспечение. Его поддержка должна включать ежеквартальный анализ выпускаемых производителем программных исправлений (patches) и встроенных программ (firmware), а также их установку у заказчика. По запросу последнего исполнитель должен принимать участие в проектировании изменений в эксплуатируемых системах.
В банке тогда объяснили CNews, что при закупках «железа» придерживаются принципа конкуренции вендоров, а приоритет отдается продукции, имеющей наименьшую стоимость владения на горизонте 5 лет для аналогичных конфигураций оборудования.
Крупных конкурсов Сбербанка на поставки программно-аппаратных комплексов, аналогичных IBM DataPower, за последнее время CNews обнаружить на портале госзакупок не удалось.
В начале февраля в банке сообщили CNews, что в вопросах закупок зарубежного «железа» внимание стало уделяться и вендорам из Юго-Восточной Азии. Так в октябре 2014 г. было подписано соглашение между Сбербанком и китайской компанией Huawei. Месяц назад банк уже использовал телекоммуникационное оборудование данного производителя и проводил тестирование его серверов и систем хранения данных. В случае успешного завершения этого процесса, Сбербанк, начиная со второго квартала текущего года, намеревался рассматривать Huawei в качестве поставщика и в данном сегменте.
IBM DataPower Gateway
Специализированная платформа для интеграции и обеспечения безопасности мобильных и облачных рабочих задач, а также задач, связанных с API, SOA, B2B и веб-приложениями
Что такое IBM DataPower Gateway?
IBM DataPower® Gateway облегчает выполнение требований организаций в области защиты и интеграции цифровых бизнес-процессов за счет единого многоканального шлюза. Это решение помогает обеспечить безопасность, контроль и интеграцию, а также предоставляет оптимизированный доступ к полному спектру рабочих задач, связанных с мобильными и облачными средами, веб-приложениями, интерфейсами программирования приложений (API), сервис-ориентированной архитектурой (SOA) и B2B. Благодаря аппаратной архитектуре нового поколения новое физическое устройство DataPower Gateway IDG X2 обеспечивает вдвое большую по сравнению с IBM DataPower Gateway(IDG) производительность. Также в этом продукте удвоена емкость флэш-накопителя и количество сетевых портов 10GbE. IDG X2 сокращает время реакции приложений и увеличивает мощность вычислений. Это особенно важно для повышения быстродействия и (или) добавления арендаторов со всеми возможностями управления и меньшей TCO.
Как клиенты используют этот продукт
Мониторинг и управление
Возможность глубокого анализа материалов со скоростью физического соединения, а также мониторинга запросов и ответов служб делает продукт удобной платформой для централизованного управления и контроля.
Защита XML от угроз и обеспечение безопасности
Устройства DataPower предоставляют организациям надежный брандмауэр XML, в котором предусмотрены сложные проверки.
Маршрутизация и объединение данных с учетом особенностей приложений
Устройство DataPower позволяет классифицировать запросы данных на основе информации, получаемой на уровне служб и приложений.
Особенности
Единая платформа многоканального шлюза
Защита, интеграция, контроль и оптимизация доставки задач по нескольким каналам, в числе которых: мобильный, API, веб, SOA, B2B и облако.
Комплексное применение политик и расширенная безопасность
Позволяет создать единую точку входа для защиты и использования согласованных политик безопасности по всем бизнес-каналам, сокращая эксплуатационные расходы и укрепляя безопасность.
Создание политик на основе конфигурации и гибкий пользовательский интерфейс
Помогает сократить время выхода на рынок и повысить эффективность работы специалистов любого уровня.
Специализированная, расширяемая платформа, готовая к использованию DMZ
Способствует динамичности бизнеса, физической безопасности, упрощенному развертыванию и управлению, снижая совокупную стоимость владения.
DataPower Operations Dashboard
Решение предназначено для централизованного поиска и получения визуального представления об операциях в реальном времени с целью ускорения определения и устранения неполадок.
Преимущества
Шлюз безопасности корпоративного класса
Безопасность корпоративного класса, соответствующая сертификатам безопасности высочайшего уровня, для критически важных корпоративных приложений.
Упрощенная интеграция
Обеспечивает быстрое преобразование сообщений, связывание транспортных протоколов, подключение к базам данных, подключение к мейнфреймам и маршрутизацию на основе содержимого, что позволяет быстро и безопасно организовывать связь между потребителями и поставщиками услуг.
Сниженная стоимость и сложность
Единый простой шлюз помогает упростить топологию и операции, а также уменьшить расходы на разработку, что позволяет добиться существенной экономии и снижения рисков.
Ценная информация и устранение неполадок
Современная рабочая консоль обеспечивает наглядное представление о транзакциях практически в реальном времени и централизованный доступ к операциям для ускорения выявления неполадок и повышения отказоустойчивости.
Обучающий курс по DataPower
Материал подготовлен в соавторстве с пользователем wedmeed
В 2017 году, когда начинался наш проект во Вьетнаме, мы столкнулись с новым для нас зверем IBM DataPower. IBM DataPower – продукт, представляющий собой gateway между клиентами и бэкендами, предназначенный для фильтрации, маршрутизации, обогащения или других преобразований проходящих через него сообщений (далее – запросов). Обучаться нужно было быстро, времени на раскачку не было, поэтому нам было предложено самостоятельно ознакомиться с ним, после чего были многочасовые конференции по скайпу с нашим коллегой из Москвы, который передавал нам свои знания и опыт работы с этим продуктом.
Самостоятельное обучение основывалось на изучении документации и просмотре обучающих видео из интернета – и тут меня ждал подвох. Мне практически не удалось найти информации на русском языке. К слову, мои знания английского языка на тот момент были не на высшем уровне, к тому же это был мой первый проект и, наверное, именно эти факторы усложнили мне жизнь. Это сподвигло меня написать обучающую статью на русском языке и в максимально простом изложении для начинающих разработчиков, которые столкнулись с этим продуктом и пытаются оперативно понять его азы. Статья не освободит вас от чтения документации, но облегчит жизнь на первых этапах понимания «как это работает».
Стоит также заметить, что приведенная в практике структура будет приближена к реальному проекту, что позволит вам использовать ее как базу, расширяя и дополняя под ваши требования. В заключение к разделам «Теория» будет приведено несколько слов об уже реализованном проекте, а также некоторые особенности, на которые стоит обратить внимание.
Часть 1. Установка DataPower средствами Docker Toolbox
Установите и запустите приложение Docker Toolbox. Сразу после запуска вы увидите IP адрес машины, по которому в дальнейшем будет доступен DataPower:
Для запуска образа необходимо изменить некоторые настройки виртуальной машины (актуально для версии IDG.2018.4.1.0) и перезапустить ее:
Примечание. Если будет предложено перезапустить «docker-machine env» — выполните:
Часть 2. Домены
2.1. Теория
Домены в DataPower позволяют разделить средства администрирования и разработки, а также обеспечить безопасность.
После установки существует только домен default, из которого могут быть созданы домены приложений. Для каждого домена существует своя конфигурация параметров.
Некоторые общие ресурсы и параметры можно определить только в default домене, к ним относятся сетевые интерфейсы, пользователи и управление доступом, домены приложений и другие.
Домен приложений – это раздел разработки для служб, обрабатывающих запросы. Службы, определенные в нём, не могу быть общими с другим доменом приложений. Домены приложений могут перезапускаться отдельно и независимо друг от друга, без необходимости полного перезапуска DataPower.
Вы можете создавать, перезапускать, сбрасывать, приостанавливать, возобновлять или удалять домены. Более подробную информацию обо всех возможностях администрирования вы можете найти в официальной документации.
Немного о реализованном проекте. Мы использовали 3 домена:
Необходимость перенести все настройки в отдельный домен возникла в связи с поиском более простого пути развертывания. Как и во многих проектах среды dev, test и prod у нас были разделены, а вынос в отдельный домен настроек позволил устанавливать все основные домены из dev среды в других средах посредством экспорта/импорта, без риска потерять настройки среды.
2.2. Практика
Часть 3. Менеджеры очередей
Менеджер очередей не является обязательным компонентом IBM DataPower, но именно на примере с MQ можно показать всю мощь этого продукта. MQ будем использовать от компании IBM. Во время тестирования, описанного в 6 главе, нам будет необходимо отправлять сообщение в локальный менеджер очередей. В данной статье я сделаю это с помощью утилиты rfhutil, но вы можете использовать любой доступный вам способ. Для тестирования необходимо будет создать коннект из DP к вашему локальному менеджеру очередей с помощью MQ Queue Manager.
3.1. Теория
Менеджер очередей обеспечивает обмен данными между шлюзом и удаленными администраторами очередей.
Вы также можете настроить MQ Queue Manager Group, что позволит повысить отказоустойчивость системы. Это может быть полезно, например, если вы хотите подключать клиента к любому из набора работающих администраторов очередей и еще в ряде случаев, с которыми вы можете ознакомиться в официальной документации.
Из опыта проекта стоит отметить только одну особенность: в свое время мы хотели попробовать реализовать балансировку нагрузки средствами DataPower, в частности, с использованием групп менеджеров очередей, но на практике не обнаружили такой возможности. Альтернативное решение – создание кластера менеджеров очередей.
3.2. Практика
3.2.1. Подготовка
При создании канала вам могут быть полезны следующие команды:
3.2.2. Создание IBM MQ Queue Manager
Проверьте состояние объекта менеджера очередей аналогично проверке статуса доменов. Для этого из домена trunk выберите Object Status и фильтр View by: types. В разделе «IBM MQ Queue Manager» отыщите соответствующий объект и проверьте его состояние.
Часть 4. Многопротокольные шлюзы
4.1. Теория
Multi-Protocol Gateway (MPG) – многопротокольный шлюз, позволяющий принимать запросы от клиентов по различным протоколам, а затем по различным протоколам передавать их на удаленный сервер. Протокол, используемый клиентом может не совпадать с протоколом, используемым сервером удаленного доступа.
В основных настройках MPG вы можете определить следующие компоненты:
Пара слов о проекте:
В реализации проекта используется 4 многопротокольных шлюза (маршрутизирующий, 2 трансформационных для разных конечных систем и дополнительный, предназначенный для получения файлов из домена settings). На схеме ниже представлена общая схема взаимодействия:
Количество MPG может варьироваться в зависимости от архитектуры решения в целом. В нашем случае DataPower стоит перед интеграционной шиной (IIB) и микросервисами, которые имеют существенные различия в интерфейсах(json/http против xml/mq), поэтому трансформационные MPG было решено делать под каждый специфический бэкенд и называть его соответствующе. Для всех клиентов мы работаем по json/http, поэтому маршрутизирующий MPG – один. Основные MPG состоят из 3 правил обработки сообщений – запроса, ответа и ошибок. Каждое правило состоит из необходимых действий, таких как transformation, logging, routing и прочие.
Из особенностей – если в policy вы используете действие ConvertQueryParamToXML, то будьте внимательны к InputConversion. Если вы зададите Default Encoding значение JSON и попытаетесь отправить GET-запрос, то будете удивлены, обнаружив, что сообщение не претерпело никаких трансформаций, указанных вами и не обнаружите никаких его следов. Данную особенность поможет преодолеть создание отдельного правила для GET-запросов.
4.2. Практика
4.2.1. Подготовка
Все необходимые для работы файлы вы можете найти по ссылке https://github.com/EvgenyaVlasenko/IBM_DataPower.git
4.2.1.1. Домен trunk
4.2.1.2. Домен settings
4.2.2. Создание GetFileMPG
Для начала создадим простой вспомогательный MPG, который будет возвращать файлы из домена settings.
4.2.3. Создание RoutingMPG
Теперь создадим RoutingMPG. На основании входного запроса и правил маршрутизации он определит, куда и с какими параметрами следует отправить запрос.
4.2.4. Создание IIBMPG
Следующий шаг – создание трансформационного MPG. Предположим, внешняя система имеет формат запроса JSON, а внутренняя — XML. Нам необходимо преобразовать входное сообщение так, чтобы его смогла понять внутренняя система. Стоит заметить, что это не всегда простое преобразование сообщения целиком. Часто требуется передать усеченное или дополненное сообщение, иногда с полностью переработанной структурой.
Часть 5. Тестирование
5.1. Подготовка
5.2. Проверка работоспособности
Часть 6. Логирование
6.1. Теория
Log Targets фиксируют различные сообщения, происходящие в системе и сохраняют их в указанном виде.
На проекте мы создали Log Targets для каждого шлюза отдельно. Логи хранятся в текстовом виде, для каждого шлюза отведено по 4 файла для логов объемом 1000Kb, при превышении лимита файлы перезаписываются циклически. При средней активности с такими параметрами информацию о запросе можно извлечь в течение 2-4 дней после его выполнения. В идеале лучше сделать внешние сборщики логов, так как при малейшем повышении нагрузки все перезапишется. Помимо этого, DataPower, как минимум, виртуальный, имеет тенденцию умирать, когда у него закончится место на жестком диске, что можно заметить далеко не сразу, а только когда заполнятся логи какого-нибудь тихого MPG, про который все давно забыли.
6.2. Практика
Часть 7. Если что-то пошло не так
Если ничего не помогло – задавайте вопросы в комментариях.
IBM DataPower Gateway: Вопросы и ответы
Получите ответы на часто задаваемые вопросы об этом продукте
Что такое DataPower® Gateway — Physical и DataPower Gateway — Virtual?
IBM DataPower Gateway – Physical отличается повышенной емкостью, производительностью и удобством использования, что облегчает выполнение важнейших требований к инфраструктуре. IBM DataPower Gateway — Virtual обеспечивает гибкость и эластичность развертывания для гипервизоров и облачных сред в форм-факторе виртуального устройства.
На что следует обратить внимание при выборе физических и виртуальных шлюзов?
Физические шлюзы предпочтительнее для задач с самыми строгими требованиями к производительности и безопасности. Виртуальные шлюзы, как правило, применяются для целей разработки и тестирования, поскольку они обеспечивают гибкость развертывания, предлагая на выбор множество вариантов развертывания в облачных средах и увеличения объема памяти.
Какие варианты развертывания доступны для IBM DataPower Gateway – Virtual?
IBM DataPower Gateway-Virtual можно развернуть в контейнере Docker, средах Microsoft Azure, VMWare ESX Server и Workstation, Citrix XenServer, Amazon EC2, IBM PureApplication® и IBM Softlayer®. Кроме того, для Softlayer возможно развертывание как на физических, так и на виртуальных серверах.
Что такое IBM DataPower Operations Dashboard?
Сводная панель предоставляет расширенные функции для централизованного устранения неполадок. Она позволяет практически в реальном времени отслеживать приложения, защищаемые и оптимизируемые с помощью шлюзов DataPower, а также анализировать состояние одного или нескольких шлюзов DataPower.
Для решения каких задач применяется IBM DataPower Gateway?
Это программное обеспечение охватывает широкий спектр сценариев использования. IBM DataPower Gateway предоставляет мобильный шлюз для собственных и гибридных мобильных приложений, а также шлюз API с высокой степенью безопасности. Он обеспечивает безопасность, интеграцию, контроль и администрирование задач SOA в DMZ и доверенной зоне.
Какие доступны возможности лицензирования?
Шлюзы в физическом и виртуальном форм-факторах можно приобрести через IBM Passport Advantage®. Стоимость физических шлюзов зависит от их количества. Виртуальные шлюзы предлагаются в трех вариантах: для рабочих сред, для нерабочих сред и для разработчиков. Образ Docker доступен бесплатно в Docker Hub без услуг поддержки IBM для целей разработки.
Какие модули входят в состав IBM DataPower Gateway?
IBM DataPower Gateway предоставляет расширяемую архитектуру и модули для улучшения защиты и интеграции. Модули с дополнительными функциями можно добавлять в оба форм-фактора (физический и виртуальный) по мере необходимости. Базовое встроенное ПО обеспечивает поддержку рабочих задач, связанных с мобильными средами, веб-приложениями и SOA.
Беглый обзор IBM Power Systems
Год назад, как участник академ. программы IBM, я прослушал курс IBM AIX 6 Jumpstart for UNIX Professionals в московском офисе IBM. Инструктор осветил большинство тем, чтобы опытный администратор Linux или UNIX сел за AIX и стал работать, а также рассказал основные положения линейки серверов IBM Power Systems. Как оказалось, это довольно интересные системы Enterprise уровня, которые предоставляют цельные бизнес системы, включающие в себя встроенные средства виртуализации, мониторинга, диагностики и т.д., которые поддерживаются и со стороны операционной системы.
Я не претендую на исчерпывающее описание архитектуры, статья — скорее экскурс в технологию, для общего развития.
И так, как я уже сказал, System P — это линейка серверов IBM, построенных на базе процессоров Power (RISC архитектура). Основное назначение — сервера приложений для бизнес систем: сервера баз данных, корпоративная переписка (например, Lotus) и разное middleware (промежуточное ПО) типа WebSphere.
На Power серверах работают 3 операционные системы: родной AIX, IBM i и, конечно же, Linux.
AIX — один из древнейших UNIX’ов, известен своей надежность, стабильностью, гибкостью и простоте управления (в основном это достигается благодаря SMIT — консольному конфигуратору системы, при помощи которого можно сделать очень много всего, не заморачиваясь с опциями командной строки). Меня поверг в шок при изучении этой системы тот факт, что на нее ставятся RPM пакеты из Linux! Под своей архитектурой, конечно, но все же. Не составило труда поставить на AIX родной mc: скачал RPM пакет для архитектуры ppc, скачал зависимости, и известной линуксоидам командой RPM я это все поставил.
IBM i — отдельная операционная система, которая мало похожа на всем известные семейства. Я о ней еще мало знаю, но друзья из банка, которые обслуживают AS/400 с IBM i, отзываются о ней как об одной из самых производительных операционок для СУБД DB2.
Linux для Power официально поддерживается только от двух производителей: RedHat, с их RHEL, и Novell, с их SLES. Сколько не искал табличку с описанием функций System P, которые не поддерживаются Linux, так и не нашел, но знаю, что такие есть. Например, очень не приятен тот факт, что ext3, в отличие от JFS2 из AIX, не поддерживает уменьшение размера раздела без отмонтирования, поэтому операции с уменьшением LVM раздела ведут к простою каких-либо сервисов.
Основные технологические «фишки» System P, выделяющие эту линейку из всего многообразия: развитый гипервизор, «ресурсы по запросу», гибкость и мобильность при построении и изменении инфраструктуры, эффективность потребления энергии, поддержка кластеризации для обеспечения высокой готовности. Цены, конечно, на первый взгляд кусаются, но в конечном итоге все перечисленные выше характеристики и технологии полностью окупают первоначальные затраты. Теперь по порядку:
Средства виртуализации
Это, наверное, самая интересная часть: в Power системах все операционки работают в виртуальных средах на базе гипервизора. Т.е. сервер может содержать несколько изолированных друг от друга «гостей», работающих одновременно, и разделяющих ресурсы. Каждый логический (виртуальный сервер) называется LPAR (Logical Partition Access Resources), в который и устанавливается операционная система. Максимальное количество LPAR на сервере зависит от количества процессоров и памяти: на один процессор можно создать максимум 10 LPAR, выделив на каждый LPAR минимальную долю в 0.1 часть ресурсов процессора и минимум по 256 Мб оперативной памяти. Теоретическое ограничение тоже есть: на 795 модели (последняя в линейке) можно создать максимум 254 LPAR. Таким образом можно оптимизировать нагрузку на сервера, поделив процессорный пул на виртуальные сервера, т.е. какому-то LPAR дать 0.5 процессора, а более нагруженному — 1.2.
Так же каждому LPAR выделяется дисковое пространство и сетевые карты. Этим занимается специальные сервер, который называется VIOS (Virtual I/O Server). Он консолидирует ресурсы: сетевые карты, дисковое пространство SAN или локальных дисков, и, согласно настройкам пользователя, отдает это все виртуальным машинам.
Но самое приятное предоставляет технология DLPAR (Dynamic Logical Partitioning): она позволяет динамически без остановки системы изменять количество ресурсов (доли процессора, память, интерфейсы ввода/вывода), выделенные для LPAR. Т.е. если я посмотрел на загрузку партиций и увидел, что одна в среднем использует 90% ресурсов, а другая 30%, я могу смело без остановки системы откусить ресурсов от второй партиции и отдать эти ресурсы первой.
Все управление гипервизором сваливается на одну из двух систем: IVM (Integrated Virtualization Manager) или HMC (Hardware Management Console). IVM идет в пакете к VIOS, и предоставляет удобный веб интерфейс для управления всем сервером. HMC — это уже отдельная машина с урезанной версией linux, которая потребуется для управления несколькими серверами. Тоже имеет удобный веб интерфейс и все сервера можно управлять прямо здесь. Веб интерфейс, конечно, можно и променять на консоль, система предоставляет оба варианта.
Ресурсы по запросу
Это скорее не фишка самой железяки, а фишка лицензирования. Она позволяет купить сервер с большИм количеством ресурсов, оставив некоторые неактивными, и заплатив за них только часть их стоимости, а затем, когда сервера уже будет не хватать, можно доплатить IBM за активацию и добавить необходимые ресурсы. Можно и не активировать все ресурсы на постоянной основе: можно активировать их на время и заплатить поминутно за использованные ресурсы. Это позволяет добавить ресурсов в моменты пиковых нагрузок, и не платить за них, когда сервер сравнительно простаивает.
Еще один довольно приятный момент: если, например, рабочий процессор выходит из строя, и есть не активированный процессор, то рабочий выключается, а неактивный включается, без доплат.
Мобильность
При построении инфраструктуры можно использовать версию PowerVM Enterprise Edition. Основная ее функция: Live Partition Mobility. Эта технология позволяет серверам пересылать друг другу LPAR’ы без их отключения даже при нагрузке. Конечно, желательно использовать быстрые каналы, SAN массивы и т.д., чтобы это все было быстро и клиенты этого даже не заметили. В IBM нам показывали как это происходит: загруженный LPAR за считанные секунды «переехал» из одного корпуса в другой, и начал там работать.
Однажды со студентами проводили эксперимент на виртуалбоксе: брали виртуальную машину и по локалке пытались переслать виртуальную машину на другой компьютер. Тогда эта функция была новой, только появилась в виртуалбоксе, и самое интересное, что она работала. Правда, как потом оказалось, только если виртуальная машина не нагружена. Стоило мне нагрузить ее — гипервизор выполнял 10 итераций и загинался с ошибкой. Само собой, 100 мегабитная локалка и общий storage в виде SMB ресурса в классе не сравнится с SAN массивом и 10ти гигабитной оптикой IBM, но попробовать стоило.
Эффективность потребления энергии
Сервера Power имеют встроенные системы управления энергопотреблением и охлаждением, которые помогают сэкономить энергию и снизить затраты, обеспечивают лучшую производительность в пересчете на ватт, а продукт Advanced POWER Virtualization позволяет консолидировать не полностью загруженные сервера, напрасно расходующие электроэнергию. Кроме того, технология EnergyScale может обеспечить уникальные возможности в управлении питанием. Эти функции позволяют пользователям измерять мощность, потребляемую компонентами системы, и настраивать политики так, чтобы работа серверной среды была эффективной с точки зрения потребления энергии.
Высокая готовность
Сервера на базе Power можно собирать в кластера, обеспечивая высокую доступность и кластерную мультиобработку. Такую технологию назвали PowerHA. Решение PowerHA обеспечивает автоматическое обнаружение сбоев, диагностику, восстановление приложений и реинтеграцию узлов. Вместе с соответствующей программной поддержкой, PowerHA может обеспечивать одновременный доступ к данным для приложений параллельной обработки, предлагая таким образом отличную масштабируемость.
Вывод: сервера на базе процессоров POWER обладают очень интересными технологическими инновациями и позволяют построить очень гибкую и устойчивую инфраструктуру.
