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”).

У кілька графіків продуктивності системи з блоковим доступом.

Хост , ОС Widows Server 2012, тестувалося два локальних диски презентованих по FC, один 100Gb c RAID10 з 4-х SSD 200Gb і другий 100Gb c пула що складається з 3-х RAID5, що мають у своєму складі 19 SAS дисків (300Gb 1 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 адаптер сервера з'єднаний зі своїм контролером системи зберігання

Завдання стоїть таке:

  1. Підключитися до СГД для керування
  2. Оновити прошивку, щоб з'явилася підтримка SAS підключень
  3. Створити з дисків array, рівень RAID 10
  4. Так як у нас сервери без жорстких дисків, створюємо для кожного сервера окремий LUN для встановлення операційної системи Windows Server 2012
  5. Створюємо один спільний LUN, який буде доступний для обох серверів. Використовуватиметься він для створення MS SQL 2012 кластера, точніше для зберігання баз даних
  6. Завдання не передбачає використання віртуалізації

Приступаємо до налаштування

1

До складу поставки системи зберігання є спеціальна флешка, вона використовується для початкового конфігурування, а саме встановлення пароля адміністратора, сервісної адреси IP для підключення до веб інтерфейсу. З флешки на комп'ютері запускаємо утиліту InitTool.bat

2

Оскільки ми щойно дістали СГД з коробки, вибираємо пункт Create a new system

3

Задаємо IP адресу, за якою підключатимемося до системи зберігання.

4

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

  1. Робимо безпечне вилучення пристрою з комп'ютера, дістаємо флешку.
  2. Дивимося на один із контролерів системи зберігання. Нам потрібно буде вставити флешку в один із роз'ємів мережевими інтерфейсами управління. Але перед цим треба переконатися, що з правої верхньої сторони контролера три світлові індикатори подають вірні семафорні сигнали, лівий горить, середній блимає, правий вимкнений.
  3. Після того, як флешка буде поміщена в 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 для кожної операційної системи. Виберіть операційну систему, щоб розпочати процес.

  1. Підготовка операційної системи IBM i у кластерному середовищі
    Див. інформацію про налаштування операційної системи для роботи з IBM WebSphere Portal. У разі встановлення інших компонентів можуть знадобитися додаткові дії; ознайомтеся з документацією щодо цих компонентів.
  2. Підготовка основного вузла IBM i
    Перед створенням кластерного середовища необхідно встановити IBM WebSphere Portalна основному вузлі і потім налаштувати базу даних та адміністратор розгортання мережі.
  3. Створення та доповнення нового профайлу Адміністратора розгортання в IBM i
    У робочому середовищі Адміністратор розгортання повинен бути встановлений на віддаленому сервері, а не на одному сервері з IBM WebSphere Portal. Для створення віддаленого профайлу Адміністратора розгортання скористайтеся Інструментом керування профайлами або командою manageprofiles. У середовищі тестування або розробки Адміністратор розгортання можна встановити в локальній системі за допомогою IBM Installation Manager. У разі встановлення віддаленого профайлу Адміністратора розгортання виконайте дії зі створення профайлу Адміністратора розгортання та його доповнення. Пропустіть ці кроки, якщо локальний профайл адміністратора розгортання встановлюється за допомогою Installation Manager на основному вузлі.
  4. Створення кластера в IBM i
    Після встановлення IBM WebSphere Portalна основному вузлі, налаштування віддаленої бази даних та підготовки основного вузла до взаємодії з адміністратором розгортання можна створити статичний кластер для обробки запитів перемикання.
  5. Підготовка веб-сервера, коли портал встановлений у IBM i у кластерному середовищі
    Встановіть та налаштуйте модуль веб-сервера, який надається IBM WebSphere Application Server, для налаштування веб-сервера для взаємодії з IBM WebSphere Portal.
  6. Кластер IBM i: Підготовка реєстрів користувачів
    Встановіть і налаштуйте сервер LDAP як реєстр користувачів, призначений для зберігання інформації про користувачів та ідентифікації користувачів у робочому середовищі з кластерами.

  7. Налаштуйте захист реєстру користувачів у IBM WebSphere Portal, щоб захистити сервер від несанкціонованого доступу. Можна настроїти автономний реєстр користувачів LDAP або додати реєстри користувачів LDAP або База даних до об'єднаного сховища за промовчанням. Після налаштування реєстру користувачів можна додати області для віртуальних порталів або допоміжну базу даних для зберігання атрибутів, які не можна зберігати в реєстрі користувачів LDAP.
  8. Підготовка додаткових елементів кластера IBM i
    Після встановлення та налаштування основного вузла можна створити додаткові вузли. Ви можете встановити IBM WebSphere Portalна кожному вузлі і потім налаштувати вузол для доступу до бази даних та реєстру користувачів, перш ніж додавати його до кластера.
  9. Кластер IBM i: Тонка настройка серверів
    Тонка настройка серверів відіграє важливу роль у забезпеченні необхідної продуктивності середовища WebSphere Portal. Спочатку WebSphere Portal не налаштований для робочого середовища, тому для забезпечення оптимальної продуктивності перегляньте та виконайте процедури з посібника IBM WebSphere Portal Tuning Guide. Якщо посібник з тонкої настройки для поточного випуску WebSphere Portal відсутній, скористайтесь посібником для попереднього випуску.
  10. Налаштування пошуку в кластері IBM i
    IBM WebSphere Portalнадає дві різні можливості пошуку. Можна використовувати обидві можливості пошуку у кластерному середовищі.
  11. Налаштування кількох кластерів у IBM i
    Додаткові кластери осередку створюються практично так само, як перший, за деякими винятками. Фактично, новий профайл буде призначений для використання як основний профайл, згідно з термінологією кластерів IBM WebSphere Portal, і буде взято за основу нового визначення кластера. Це копіює процес створення першого кластера в комірці. Під час процесу розповсюдження за наявності будь-яких додатків у цьому новому вузлі в осередку (оскільки вони використовуються першим кластером) Адміністратор розгортання не дозволить додати їх. Після розповсюдження програми, які вже існують у осередку, не відображаються на сервер WebSphere_Portal на новому доданому вузлі; таким чином, існуючі програми слід заново прив'язати до нового поширеного сервера для відновлення списку програм. Таким чином, залежно від конфігурації нового профайлу, деякі програми будуть використовуватися спільно іншими існуючими кластерами, а деякі - унікальними для цього нового профайлу.
  12. Спільне використання доменів бази даних між кластерами 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- 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.1.1.

Відключаємо зайвий 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. Як це зробити? Є два способи, через папку /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 на інший сервер і все буде працювати з коробки. Дуже зручно. Тобто. ми можемо заздалегідь налаштувати потрібне нам СП і робити поставки цілого пакета програмного забезпечення відразу. А ще "вебсфера ліберті" дуже легка і запускається/зупиняється дуже швидко:)

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