IBM Storwize V7000 Unified - описание, подключение и настройка СХД. IBM Storwize V7000 Unified - описание, подключение и настройка СХД Организация хранилища данных

В сегодняшнем посте речь пойдет о IBM Storwize V7000 Unified.

Рассмотрим вопросы подключения и инициализации, а так же проведем небольшой тест производительности.

Для начала немного справочной информации по :

IBM Storwize V7000 Unified - это унифицированная системы хранения данных, с возможностью одновременного предоставления блочного и файлового доступа (SAN и NAS). Файловый доступ по средствам файловых протоколов NFS/CIFS/FTP/HTTPS/SCP. А так же локальной и удаленной репликацией файлов. Ну и плюс все полезности и вкусности присущие оригинальному Storwize V7000, а это: Thin Provisioning (виртуальное выделение дискового пространства), FlashCopy (создание снимков и клонов томов), Easy Tier (многоуровневое хранение), Data Migration (миграция данных), Real-time Performance, Metro and/or Global Mirror (удаленная репликация), External Virtualization (виртуализация вешних СХД), Real-time Compression(компрессия данных).

Состоит система из самой V7000 и двух файловых модулей (своеобразный сервер system x с установленным на него специализированным по) объединённых в кластер под управлением единого графического интерфейса, как говорят в IBM - одна система, одно управление, одно унифицированное решение.

Инсталляция и инициализация системы довольно проста, главное убедится в правильной коммутации и иметь четкое представления о порядке действий, а так же не помешает посетить IBM Storwize V7000 Unified Information Center (http://pic.dhe.ibm.com/infocenter/storwize/unified_ic/index.jsp?topic=%2Fcom.ibm.storwize.v7000.unified.132.doc%2Fmanpages%2Fdetachnw.html)

Пример коммутации системы IBM Storwize V7000

Для инициализации выполняем следующий порядок действий:

Жмем “Launch GUI” откроется браузер по ip заданном в пункте Management IP, где мы увидим процесс инициализации системы. По окончанию указав все необходимые параметры нас ждет уже знакомый, но наполненный новыми пунктами GUI.

Если же что-то пошло не так и при инициализации возникла проблема, стоит обратит внимание на файл “satask_result.html” находящийся на флэшке с утилитой, как правило он содержит номер ошибки из-за которой произошёл сбой. Повторная инициализация вряд ли удастся если хоть один из элементов системы уже был сконфигурирован, поэтому все настройки надо сбросить. Сброс производится следующим образом: на самой СХД нужно зайти на сервисный графический интерфейс контролеров (ip адрес можно сменить при помощи все той же InitTool утилиты, по умолчанию используется адрес 192.168.70.121/122), перевести node1 и node2 в режим сервисного обслуживания (“Enter Service State”), затем на вкладке “Manage System” очистить системную информацию выбранной ноды, далее идем на вкладку “Configure Enclosure” и сбрасываем ID системы (ставим галочку на “Reset the system ID” и жмем “Modify”), данную последовательность действий нужно произвести для обоих контроллеров (поочередно выбрав на вкладке ”Home” node1 и node2), после чего обязательно нужно перезагрузить СХД. Для удаления конфигурации на файловых модулях нужно переустановить систему с диска идущего в комплекте, предварительно выполнив команды на загруженных модулях, username/password (root/Passw0rd), далее ($ rm -rf /persist/* ), и проверяем что файл удален ($ ls -ahl /persist/* ), вставляем диск и перезагружаем ($ reboot ), установка начнется автоматически после подтверждения (жмем “Enter”).

В к несколько графиков производительности системы c блочным доступом.

Хост , ОС Widows Server 2012, тестировалось два локальных диска презентуемых по FC, один 100Gb c RAID10 из 4-х SSD 200Gb и второй 100Gb c пула состоящего из 3-х RAID5, имеющих в своем составе 19 SAS дисков (300Gb 15k), две RAID группы включали в себя по семь дисков, а третья пять. Тестирование проводили программой IOmeter, применялись две спецификации “100%Random-8k-70%Read” - тест блоками по 8kb, 100% случайным доступом, 70% операции чтения, 30% запись. И “Max Throughput-50%Read” - тест блоками по 32kb, 100% последовательны доступом, 50% операции чтения, записи. Глубина очереди имела значение 64.

Хочется показать, насколько просто можно настроить систему хранения данных от IBM. Отдельное спасибо за предоставленные скриншоты нужно сказать Дмитрию К. из Оренбурга, который не поленился и запечатлел процесс инсталляции.

Самая элементарная схема:

СХД IBM Storwize v3700 в базовой комплектации с возможностью подключения серверов по iSCSI и SAS. Установлены 4 диска по 600Gb
два сервера IBM 3650 m4, без локальных дисков, с двумя однопортовыми SAS HBA картами
подключение крест на крест, отказоустойчивое — каждый HBA адаптер сервера соединен со своим контроллером системы хранения

Задача стоит следующая:

Подключиться к СХД для управления
Обновить прошивку, чтобы появилась поддержка SAS подключений
Создать из дисков array, уровень RAID 10
Так как у нас серверы без жестких дисков, создаем для каждого сервера отдельный LUN для установки операционной системы Windows server 2012
Создаем один общий LUN, который будет доступен обоим серверам. Использоваться он будет для создания MS SQL 2012 кластера, точнее для хранения баз данных
Задача не предполагает использование виртуализации

Приступаем к настройке

1

В состав поставки системы хранения есть специальная флешка, она используется для первоначального конфигурирования, а именно установка пароля администратора, сервисного IP адреса для подключения к веб интерфейсу. С флешки на компьютере запускаем утилиту InitTool.bat

2

Так как мы только что достали СХД из коробки, выбираем пункт Create a new system

3

Задаем IP адрес, по которому будем подключаться к системе хранения.

4

Процесс инициализации системы:

Делаем безопасное извлечение устройства из компьютера, достаем флешку.
Смотрим на один из контроллеров системы хранения. Нам нужно будет вставить флешку в один из разъемов по сетевыми интерфейсами управления. Но перед этим нужно убедиться, что с правой верхней стороны контроллера три световых индикатора подают верные семафорные сигналы, левый горит, средний мигает, правый выключен.
После того, как флешка будет помещена в USB порт (любой). Начинает мигать правый значок (восклицательный). Необходимо дождаться пока он перестанет потухнет, после этого можно извлечь флешку и вернуть ее обратно в компьютер, чтобы закончить шаги мастера.

5

Через браузер (рекомендуется IE8 или Firefox 23+) заходим на веб интерфейс.

По умолчанию логин пароль для входа superuser — passw0rd (через ноль)
Теперь самое время обновить прошивку, для этого переходим в меню Settings -> General -> Upgrade Machine Code

Прошивка заранее скачана с официального сайта ibm.com. В нашем случае это Version 7.1.0.3 (build 80.3.1308121000). В ее составе есть Upgrade test utility, сначала загружаем на СХД ее, а затем саму прошивку.

6

СХД автоматически определила 4 установленных диска. Три из них система отдала под POOL, один назначила под hot spare.

Если бы дисков было больше, может быть имело бы смысл оставить подобную автоматическую настройку. В нашем случае лучше переразбить диски по-другому.

7

Удаляем автоматически созданный Pool

8

Получаем 4 свободных диска, из которых предстоит создать RAID 10

9

Нажимаем Configure Storage, затем выбираем какой именно RAID мы хотим создать и сколько дисков будет задействовано под него.

10

Задаем название для вновь создаваемого Pool.

Чтобы не запутаться в терминах. Из свободных дисков мы создаем RAID или array, получившееся свободное пространство это Pool. Затем сам пространство пула будем нарезать на кусочки, так называемые LUN-ы или Volume и вот их уже можно будет презентовать серверам (хостам).

11

Pool создался

12

Создаем новый LUN в пуле

13

На скриншоте не видно, но мы задаем размер LUN-а

14

Таким образом, используя мастер создания LUN-ов делаем 3 луна.

Как и было задумано, два по 100Gb под операционные системы серверов. И один общий размером 500Gb для создания кластера MS SQL 2012

15

Теперь необходимо сообщить системе хранения данных, какие серверы (host) к ней подключены. В базовой комплектации всего два варианта соединения — это iSCSI и SAS.

У нас два сервера, которые подключены к Storwize v3700 по SAS

16

На этом шаге мы указываем системе хранения, что наш первый сервер подключен к ней двумя SAS кабелями, которые в сервере воткнуты в две SAS HBA карты со идентификаторами (16-ти значные)

Таким образом добавляем оба сервера, у каждого два идентификатора.

17

Презентуем LUN-ы серверам. Другими словами назначаем права доступа.

На скриншоте HOST_LUN_TOP предназначен только для первого сервера, т.к. на него будет установлена его операционная система. И второму серверу этот LUN видеть нельзя.
В отличии от SQL_LUN, который должен быть доступен обоим серверам, ведь на нем будут располагаться базы данных MS SQL кластера.

Для настройки и дальнейшего управления системами хранения дынных серии DS35xx от IBM используется программа DS storage manager, последнюю версию которой можно скачать с официального сайта, конечно, после регистрации. Есть версии программы для разных операционных систем, Linux, Windows, Mac, HPUX

Здесь же, не лишним будет скачать последние обновления прошивки контроллеров системы хранения. Иначе СХД может не увидеть дисков или HBA адаптеры в серверах или возникнут другие сопутствующие проблемы.

Не знаю почему, но у многих возникают проблемы с поиском и скачиванием на сайте IBM файлов для загрузки. Заходим на Ibm.com -> Support and Downloads -> Fixes, updates and drivers -> Quick find-> в строке поиска "DS3500 (DS3512, DS3524)" -> View DS3500 (DS3512,DS3524) downloads. Портал IBM не всегда корректно отрабатывает, поэтому если не получается, попробуйте другой браузер.

Прошивки на контроллер, выглядят так

Файлы для загрузки DS storage manager, так

После установки и запуска программы, предлагается выбрать метод нахождения СХД. Automatic сканирует сеть и ищет подключенную DS35xx, в Manual нужно вручную ввести IP адреса обоих контроллеров нашей СХД. Адреса интерфейсов управления, которые заданы по умолчанию, для удобства написаны на самой системе хранения под портами. Если в сети работает DHCP, то адреса будут получены автоматически.

Мы видим, что для отказоустойчивости в каждый контроллер встроены по два порта управления, но, обычно, для управления используются первые порты каждого контроллера.

Схема подключения

Перед началом настройки нужно представлять, что хотим получить в итоге, если понимания нет, то и начинать не стоит. Сделаем самую простую схему, подключим к системе хранения два сервера по схеме.

В каждом сервере два SAS HBA адаптера, для тех кто не знает, это просто карта PCI-E, с входом SAS. По два HBA установлено для отказоустойчивости, если один из контроллеров в СХД выйдет из строя, то работа будет продолжена через другой. По такой же логике система защищена от проблем с SAS кабелем или HBA адаптером в сервере.

Настройка. Логика.

У нас есть СХД, в ней диски. Сначала нам нужно из дисков собрать какой-нибудь RAID (array), потом на этом RAID создать логический том (LUN), затем презентовать этот том серверам (mapping), чтобы они его увидели и могли с ним работать. Вот такая логика.

Теперь по порядку. Я буду совершать все манипуляции в симуляторе, скачать который можно на официальном сайте хранилищ IBM. Интерфейс не один в один повторяет то, что вы увидите на реальной DS3524 или DS3512

1.. Мы ранее выбрали автоматический метод поиска системы хранения, система нашла и подключила ее, СХД отображается в консоли.

2.. Кликаем правой кнопкой по СХД, выбираем пункт Manage, чтобы начать настройку.

3.. В новом окне открывается мастер, но т.к. я хочу показать универсальную последовательность действий, закрываем его.

4.. В закладке Logical/Physical View видим нераспределенное дисковое пространство. В симуляционной СХД диски двух типов, мы настроим привычные SATA. Сначала создаем Array (RAID)

6.. Задаем ИМЯ нашему array

7.. Выбираем, какой именно RAID мы хотим получить. Не видим 10 RAID, чтобы его создать нужно выбрать RAID 1

8.. И тут же мастер объясняет, что если вы создаете RAID 1 из четырех и более дисков, то автоматически создастся 10 RAID (или 1+0, то же самое)

9.. Выбираем создание RAID из 38 дисков

10.. После создания, автоматически запускается мастер создания тома (LUN), его также можно запустить и из консоли, как в 4-ом шаге, только выбирать надо созданный ранее array.

11.. Нужно указать размер LUN, в моем случае 8 Tb (всего свободно 17,6 Tb), и придумать название для тома

12.. Важный момент, если мы знаем, какая ОС будет установлена в этот LUN то нужно указать ее. Для VMware тоже есть строчка, для XenServer выбирается Linux. А у меня в симуляторе почему-то этих строчек нет

13.. После создания Array и LUN мы их видим в консоли

14.. Теперь необходимо перейти на другую вкладку и дать доступ к этому LUN серверу. Видим, что по умолчанию создана группа Default Group и этой группе доступен LUN1. Нам достаточно добавить наш сервер (сначала один, затем другой) в это группу, чтобы они могли подключиться к LUN1.

15.. Кликаем правой кнопкой мыши по Default Group, Define -> Host

16.. У каждого нашего сервера есть по два SAS HBA, именно через них происходи подключение к СХД. Система хранения может идентифицировать сервер именно по HBA адаптерам, а точнее, по их уникальным «identifier».

Задаем имя хосту (у меня ESX1). Выбираем два «identifier», которые принадлежат серверу, который мы подключаем. Посмотреть, какие идентификаторы у сервера, можно подключившись к ESXi хосту напрямую через vSphere Client или через vCenter Server. Там в искать разделе «storage adapters».

Переносим два «identifier» из левой колонки в правую. Затем выбираем каждый «identifier» и жмем на кнопку Edit, чтобы добавить и к нему описание. Такая процедура придумана для того, чтобы не запутаться в большом количестве идентификаторов.

У меня в симуляторе, какие-то нули вместо уникальных «identifier», не обращайте внимания, у вас все будет как положено.

17.. Теперь выбираем операционную систему хоста, если VMware то выбираем VMware

18.. После этого в консоли вы увидите свой Host и из-за того что он находится в группе Default Group, ему будет доступен LUN1.

Заключение. Получилась длинная статья, на практике все происходит намного быстрее, достаточно пару раз прощелкать все действия и процесс подключения систем хранения от IBM больше не будет взывать проблем.

Чуть сложнее настраивается подключение по iSCSI. Советую выбирать или SAS или FC.

Кластеры позволяют масштабировать конфигурацию IBM® WebSphere Portal . Кроме того, кластеры обеспечивают высокую готовность приложений J2EE, поскольку в случае сбоя запросы автоматически пересылаются на исправные серверы. Кластер можно настроить различными способами: горизонтальный, вертикальный, множественный и динамический.

На следующей иллюстрации изображена конфигурация горизонтального кластера, в которой WebSphere Portal установлен на нескольких серверах или в нескольких профайлах на одном физическом сервере. Конфигурация с несколькими серверами уменьшает количество отдельных сбоев, но требует дополнительного программного обеспечения, например, серверов. Конфигурация с несколькими профайлами также сокращает количество отдельных сбоев. Она требует меньше дополнительного аппаратного обеспечения, чем конфигурация с несколькими серверами, но тем не менее дополнительное аппаратное обеспечение, например дополнительная память, может потребоваться. Администратор развертывания управляет ячейкой для узлов горизонтального кластера.

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

В ответ на пожелания пользователей приведены инструкции по настройке WebSphere Portal для каждой операционной системы. Выберите операционную систему, чтобы начать процесс.

Подготовка операционной системы IBM i в кластерной среде
См. информацию по настройке операционной системы для работы с IBM WebSphere Portal . В случае установки других компонентов могут потребоваться дополнительные действия; ознакомьтесь с документацией по этим компонентам.
Подготовка основного узла в IBM i
Перед созданием кластерной среды вы должны установить IBM WebSphere Portal на основном узле и затем настроить базу данных и администратор сетевого развертывания.
Создание и дополнение нового профайла Администратора развертывания в IBM i
В рабочей среде Администратор развертывания должен быть установлен на удаленном сервере, а не на одном сервере с IBM WebSphere Portal . Для создания удаленного профайла Администратора развертывания воспользуйтесь Инструментом управления профайлами или командой manageprofiles . В среде тестирования или разработки Администратор развертывания можно установить в локальной системе с помощью IBM Installation Manager . В случае установки удаленного профайла Администратора развертывания выполните действия по созданию профайла Администратора развертывания и его дополнению. Пропустите эти шаги, если локальный профайл Администратора развертывания устанавливается с помощью Installation Manager на основном узле.
Создание кластера в IBM i
После установки IBM WebSphere Portal на основном узле, настройки удаленной базы данных и подготовки основного узла к взаимодействию с Администратором развертывания можно создать статический кластер для обработки запросов переключения.
Подготовка веб-сервера, когда портал установлен в IBM i в кластерной среде
Установите и настройте модуль веб-сервера, предоставляемый IBM WebSphere Application Server , для настройки веб-сервера для взаимодействия с IBM WebSphere Portal .
Кластер IBM i: Подготовка реестров пользователей
Установите и настройте сервер LDAP в качестве реестра пользователей, предназначенного для хранения информации о пользователях и идентификации пользователей в рабочей среде с кластерами.
Настройте защиту реестра пользователей в IBM WebSphere Portal , чтобы защитить сервер от несанкционированного доступа. Можно настроить автономный реестр пользователей LDAP или добавить реестры пользователей LDAP или База данных в объединенное хранилище по умолчанию. После настройки реестра пользователей вы можете добавить области для виртуальных порталов или вспомогательную базу данных для хранения атрибутов, которые нельзя хранить в реестре пользователей LDAP.
Подготовка дополнительных элементов кластера в IBM i
После установки и настройки основного узла вы можете создать дополнительные узлы. Вы можете установить IBM WebSphere Portal на каждом узле и затем настроить узел для доступа к базе данных и реестру пользователей, прежде чем добавлять его в кластер.
Кластер IBM i: Тонкая настройка серверов
Тонкая настройка серверов играет важную роль в обеспечении требуемой производительности среды WebSphere Portal. Изначально WebSphere Portal не настроен для рабочей среды, поэтому для обеспечения оптимальной производительности просмотрите и выполните процедуры из руководства IBM WebSphere Portal Tuning Guide. Если руководство по тонкой настройке для текущего выпуска WebSphere Portal отсутствует, воспользуйтесь руководством для предыдущего выпуска.
Настройка поиска в кластере IBM i
IBM WebSphere Portal предоставляет две различные возможности поиска. Можно использовать обе возможности поиска в кластерной среде.
Настройка нескольких кластеров в IBM i
Дополнительные кластеры ячейки создаются практически так же, как первый, за некоторыми исключениями. Фактически, новый профайл будет предназначен для использования в качестве основного профайла, согласно терминологии кластеров IBM WebSphere Portal , и будет взят за основу для нового определения кластера. Это копирует процесс создания первого кластера в ячейке. Во время процесса распространения при наличии каких-либо приложений в этом новом узле в ячейке (так как они используются первым кластером) Администратор развертывания не позволит добавить их. После распространения приложения, уже существующие в ячейке, не отображаются на сервер WebSphere_Portal на вновь добавленном узле; таким образом, существующие приложения следует заново привязать к новому распространенному серверу для восстановления списка приложений. Таким образом, в зависимости от конфигурации нового профайла, некоторые приложения будут использоваться совместно прочими существующими кластерами, а некоторые - уникальными для этого нового профайла.
Совместное использование доменов базы данных между кластерами в IBM i
Если рабочая среда состоит из нескольких кластеров в одной ячейке и нескольких кластеров в разных ячейках, то для поддержки избыточности и восстановления после сбоя можно предоставить доступ к доменам базы данных всем кластерам. Данные IBM WebSphere Portal хранятся в нескольких доменах базы данных с различными требованиями к уровню готовности, зависящими от конфигурации рабочей среды. При наличии нескольких технологических линий, каждая из которых реализована в виде кластера серверов, применение общих доменов базы данных гарантирует автоматическую синхронизацию данных между технологическими линиями.

В данной статье, мы рассмотрим вопрос установки и настройки на CentOS 7 . В данном мануале, будет продемонстрирована установка trial версии WebSphere , но она ничем не отличается от полной версии, так что это не имеет значения.

Итак, поехали!

1) Подготовка и настройка ОС

В нашей работе мы будем использовать новую CentOS 7 . На удивление, но “из коробки” ее нужно нехило так допилить до рабочего состояния, так что будьте к этому готовы. Итак, устанавливаем минимальную версию без графики и поехали. Через интерфейс – настройте сразу сеть, чтобы был интернет… это значительно облегчит вашу участь:)

Установим базовое ПО… которого почему-то нет в поставке:

Yum install net-tools nano wget

Теперь проверим наш hostname и поправим hosts (поправьте как вам нравится):

Nano /etc/hostname nano /etc/hosts

Ifconfig -a

Чтобы это исправить, надо сначала поправить немного grub :

Nano /etc/default/grub

В конце строки “GRUB_CMDLINE_LINUX ” нужно добавить “net.ifnames=0 biosdevname=0 “. Получится что-то типа такого (не обязательно 1 в 1):

GRUB_CMDLINE_LINUX="rd.lvm.lv=rootvg/usrlv rd.lvm.lv=rootvg/swaplv crashkernel=auto vconsole.keymap=usrd.lvm.lv=rootvg/rootlv vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0 "

Переименовываем наш сетевой интерфейс на нормальный, классический “eth0 ” и ребутимся:

Mv /etc/sysconfig/network-scripts/ifcfg-ens32 /etc/sysconfig/network-scripts/ifcfg-eth0 reboot

Настраиваем сеть:

Nano /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" ONBOOT=yes BOOTPROTO=static IPADDR=1.1.4.185 NETMASK=255.255.248.0 GATEWAY=1.1.1.9 DNS1=1.1.1.10 DNS2=1.1.1.90

Отключаем лишний Network manager и ребутимся:

Systemctl stop NetworkManager systemctl disable NetworkManager reboot

Проверяем, обозначен ли в системе как-нить IPv6 :

Lsmod | grep -i ipv6

Если сообщения будет иметь упоминания об IPv6 , а оно будет, то переходим к его отключению:

Nano /etc/default/grub

В начале строки “GRUB_CMDLINE_LINUX ” нужно добавить “ipv6.disable=1 “. Получится что-то типа такого:

GRUB_CMDLINE_LINUX="ipv6.disable=1 rd.lvm.lv=rootvg/usrlv...

Создаем новый конфиг и сохраняем результат:

Grub2-mkconfig -o /boot/grub2/grub.cfg

Перезагружаемся:

Проверяем еще раз и убеждаемся, что все красиво:

Lsmod | grep -i ipv6

Добавляем в систему EPEL (всякие “отягощенные” лицензиями пакеты) репозиторий для CentOS 7 :

Wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm rpm -ivh epel-release-7-2.noarch.rpm yum repolist

Новая ОС использует “главного” демона, управляющего другими демонами. Это systemd , который ввели вместо устаревших скриптов инициализации init.d . Также используется новый фаервол, firewalld вместо iptables . Проверим его работу и откроем нужные нам порты (9080 и 9443):

Systemctl status firewalld firewall-cmd --permanent --zone=public --add-port=9080/tcp firewall-cmd --permanent --zone=public --add-port=9443/tcp systemctl restart firewalld

Собственно говоря, на этом настройка ОС заканчивается и мы переходим непосредственно к установке IBM WebSphere Application Server Liberty Profile 8.5.5

2) Установка WebSphere

Нам потребуется учетная запись IBM . После обычной регистрации можно скачать любое ПО (в целях разработки, оно еще называется trial version ).

Напрямую ПО скачивать не дают. Мы скачиваем универсальный Installation Manager , и потом уже через него мы сможем скачать нужное нам ПО. Содержимое архива BASETRIAL.agent.installer.linux.gtk.x86_64.zip распаковываем в папку was и ее же потом закачиваем на сервер в /root

Даем права и запускаем установку:

Chmod -R 775 /root/was cd was ./installc -c

Первым делом, Installation Manager попросит нас ввести наш логин и пароль от учетки IBM. Нажимаем p и вводим учетные данные:

Выбираем для установки только следующие пункты (installation manager, websphere liberty и java sdk для нее):

А вот фиксы ставить не будем. Они не обязательные к установке, к тому же баганутые и устанавливаются с ошибкой:

Итоговое сообщение. Что и куда устанавливается:

После этого – ждем. Сколько ждать? Зависит от скорости вашего Интернета и загруженности серверов IBM . Необходимо будет скачать около 500 мб, а то и больше. Запаситесь терпением… Что происходит? Инсталлятор подключает свои репозитории и скачивает с него заказанное ПО. Все красиво.

Сообщение об успешной установке выглядит так:

Теоретически, возможна также установка всего этого через response files, без диалогов. Но этот вариант также требует уже установленного Installation Manager , так что в нашем случае это не актуально..

Итак, все! мы установили IBM WebSphere Application Server Liberty Profile 8.5.5 и необходимую для его работы Java ! Поздравляю! Сейчас мы рассмотрим, что можно сделать дальше.

3) Настройка WebSphere

а) Запуск WebSphere

Давайте создадим наш тестовый сервер:

/opt/IBM/WebSphere/Liberty/bin/server create PROJECT

Создали. Появилась папка: /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT Все настройки и будущие модули, будут находится именно в ней. Чтобы запустить данный СП, надо добавить в главный его конфиг строку host=’1.1.4.185′ (с нашим IP), над httpPort=’9080′ (это тут: /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT/server.xml ). Пример такого конфига:

Запускаем:

/opt/IBM/WebSphere/Liberty/bin/server start PROJECT

Перейдя по адресу http://1.1.4.185:9080 , увидим следующее:

Это значит, что все хорошо и вебсфера запустилась.

б) Установка модуля администрирования

Этот пункт не является обязательным. Но с модулем администрирования работать с вебсферой удобнее. Через него, можно останавливать и запускать модули по отдельности, без необходимости остановки всего сервера.

Итак, устанавливаем этот модуль:

/opt/IBM/WebSphere/Liberty/bin/featureManager install adminCenter-1.0 --when-file-exists=ignore

Для входа в админку под админом, используем учетную запись: admin/password. А под пользователем: nonadmin/nonadminpwd.

Адрес входа на нее: http://1.1.4.185:9080/adminCenter/ Выглядит админка так:

Все! Модуль администрирования установлен.

в) Установка модуля расширений

Также, на Вебсферу нужно установить extended пакеты (расширенный набор библиотек и бинарников), делается это предельно просто:

/opt/IBM/WebSphere/Liberty/bin/featureManager install extendedPackage-1.0

г) Установка модулей

Мы подошли к самому интересному. Установка модулей в Liberty. Как же это сделать? Есть 2 способа, через папку /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT/dropins и /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT/apps
Из каталога dropins модули подхватываются и устанавливаются автоматически. Из каталога apps – их нужно вручную прописать в конфиге server.xml. Пример конфига, к котором подключается модуль через apps:

Для запуска СП не в фоне и с логами, выполните команду:

/opt/IBM/WebSphere/Liberty/bin/server run PROJECT

д) Плюсы

Тестированием проверено, что достаточно скопировать папку /opt/IBM на другой сервер и все будет работать из коробки. Очень удобно. Т.е. мы можем заранее настроить нужный нам СП и делать поставки целого пакета ПО сразу. А еще “вебсфера либерти” очень легкая и запускается/останавливается очень шустро:)

Опубликовано