Технологія PowerFlex: Пояснення функції запуску сценарію на хості (також відомого як виправлення ОС)

Інтерфейс користувача - Pre-PFMP (PowerFlex 4.x)

Передумови

Обов'язковий - основний скрипт знаходиться в /opt/emc/scaleio/lia/bin/ каталог з правами на виконання.

• Ім'я скрипту має бути patch_script 

Необов'язковий - скрипт валідації знаходиться в /opt/emc/scaleio/lia/bin/ каталог з правами на виконання.

• Ім'я скрипту має бути verification_script

> Ця функція підтримується лише на Linux (RHEL та SLES).
> Ця функція перевіряє, чи є код виходу 0 (Нуль) наприкінці виконання.
> Коди виходу та запуск скриптів можна знайти в журналах LIA.
> Клієнт несе відповідальність за тестування patch_script та verification_script перед запуском процесу за допомогою шлюзу.
> Особливості розташування: Ведіть → системні журнали та аналіз, → запускайте скрипт на хостів.

Етапи та потоки

Виконання сценарію на:
1. Вся система - всі вузли
PowerFlex За замовчуванням скрипт виконується на домені захисту (PD) першого хоста, потім переходить до другого і так далі.
Паралельно на різних доменах захисту відключений - за замовчуванням знімається галочка.
 
Паралельно на різних доменах захисту включено - вибравши цю опцію, patch_script буде працювати паралельно на всіх ПД.
PD, які не мають MDM, є першими, а вузли кластера — останніми.


2. Домен захисту - це конкретні PD PD
, які не мають MDM, є першими, а вузли кластера MDM - останніми.

3. Fault Set - це конкретна ФС.
ФС, які не мають MDM, є першими, а вузли кластера MDM – останніми.

4. SDS - один вузол


SDSКонфігурація виконання:
1. Зупиніть процес у разі збою сценарію.
1.1 Зупинка процесу при збої скрипта включена - за замовчуванням галочка поставлена.
Весь запуск зазнає невдачі та зупиниться, як тільки patch_script (і verification_script, якщо вибрано) вийде з будь-яким іншим кодом, крім 0 (Нуль).
 
1.2 Зупинка процесу при збої сценарію відключена.
У разі, якщо patch_script вийде з ладу, виконання цього вузла зазнає невдачі, і система перейде на наступний вузол і запустить patch_script на цьому вузлі.
 

2. Тайм-аут сценарію - скільки часу чекати закінчення patch_script?
Запуск скрипта має налаштовуваний тайм-аут, який вибирає користувач.
За замовчуванням налаштований на 15 хвилин → через помилку, тайм-аут жорстко закодований до 15 хвилин, у версіях старше PowerFlex 3.6.
Весь запуск зазнає невдачі та зупиниться, як тільки час виконання сценарію закінчиться.

3. Скрипт перевірки - Чи хочете ви запустити verification_script після того, як patch_script було запущено?
3.1 Run - patch_script запуститься, і як тільки це буде зроблено, verification_script запуститься, в залежності від того, чи було patch_script дії після перезавантаження чи ні (розділ #4).
3.2 Do not Run - patch_script буде бігти, і як тільки це буде зроблено, весь біг зупиниться і закінчиться так само успішно.
 

4. Дія після скрипту - Чи хочете ви перезавантажити вузол після виконання patch_script?
4.1 Перезавантаження - після того, як patch_script закінчиться біг і вийде з кодом 0 (Zero), вузол перезавантажиться, і зупиниться або продовжить в залежності від того, чи був обраний verification_script для запуску чи ні (розділ #3).
Якщо Gateway знаходиться на вузлі, який потрібно перезавантажити, він не перезавантажиться, операція проходить успішно, і буде показано спливаюче вікно, яке нагадує нам перезавантажити його вручну.
4.2 Не перезавантажуватися - після того, як patch_script закінчили біг і вийшли з кодом 0 (Zero), вузол не буде перезавантажуватися, а зупинятися або продовжувати в залежності від того, чи був обраний verification_script для запуску чи ні (розділ #3).
 


Запустіть скрипт на хостів:
Натисніть "Run Script on Hosts" ->Validate phase starts.
На цьому етапі надсилається запит до LIA кожного вузла для перевірки існування файлів patch_script та verification_script (якщо вибрано) під /opt/emc/scaleio/lia/bin/.
Логіка коду вибирає випадковий список вузлів для роботи (відповідно до згаданих умов).
 


Початковий етап виконання:
Натисніть кнопку «Запустити фазу виконання».
1. Шлюз робить такі перевірки:

a. Перевірте, чи немає несправної ємності.
b. Перевірте допустиму вільну ємність.
c. Перевірте дійсний стан кластера.
d. Переконайтеся, що жоден інший SDS не перебуває в режимі обслуговування.

2. Переведіть SDS у режим технічного обслуговування.
3. Запустіть patch_script - після вдалого запуску файл видаляється і створюється файл з нього резервної копії в тому ж каталозі.
З назвою backup_patch_script
4. Перезавантажити хост (якщо вибрано
)5. Run verification_script (якщо вибрано) - після вдалого запуску файл видаляється і створюється файл його резервної копії в тому ж каталозі з ім'ям backup_verification_script.
6. Вийдіть з режиму технічного обслуговування SDS.
7. Операція завершена успішно.


 

RESTAPI - Post-PFMP (PowerFlex 4.x)

• Запустіть сценарій виправлення на всіх або деяких системних вузлах з необов'язковим перезавантаженням і необов'язковим сценарієм перевірки. Операція має певний рівень паралелізму.
• Файли скриптів повинні зберігатися в папці вузла: /opt/emc/scaleio/lia/bin Крім того, вони можуть бути завантажені GW на вузол. Скрипти можуть бути взяті з локальної папки GW або завантажені з спільного доступу HTTP/HTTPS.
• Список SdsId та/або mdmId може бути наданий, щоб явно вибрати вузли для роботи.
• Назви файлів жорстко закодовані і не можуть бути змінені: patch_script і verification_script

Команда REST

• /im/types/Configuration/actions/liaRunOsPatching

необхідні параметри

• Обов'язковим є будь-який з наступних параметрів: pdIds/fsIds/sdsIds/mdmIds / executeOnAllSdss / executeOnAllMdms
  • pdIds  - запускаються на всіх вузлах, які входять до наступних доменів захисту (PD Ids), у десятковому форматі
  • fsIds  - виконується на всіх вузлах, які входять до наступних наборів несправностей (FS Ids), у десятковому форматі
  • sdsIds  - запускається на всіх SDS, перелічених Ids, у десятковому форматі
  • mdmIds  - запускається на всіх MDM, перелічених за ідентифікаторами, у десятковому форматі
  • executeOnAllSdss  - працювати на всіх SDS (true/false)
  • executeOnAllMdms  - запускається на всіх MDM (true/false)

Необов'язкові параметри

• isRebootRequired - чи повинен кожен вузол перезавантажуватися після запуску сценарію патчу (значення: true/false)
• isVerificationScriptRequired - чи повинен скрипт перевірки виконуватися на кожному вузлі (значення: true/false)
• isRunningInParallelOnPds - чи повинна операція виконуватися паралельним способом на вузлах, які належать до різних ПД (значення: true/false)
• isStopProcessingOnScriptFailure - чи повинна вся операція зупинятися у випадку збою скрипту (значення: true/false)
• TimeoutMs - тайм-аут для запуску сценарію патчу в мілісекундах
• isUploadFileNeeded  - Чи повинен GW завантажувати скрипти на вузли (значення: true/false)

Наступні поля актуальні, коли isUploadFileNeeded  є «істинним»:

• patchScriptFilePath  - або ім'я локальної папки, або URL-адреса http/https скрипта патчу
• verificationScriptFilePath  - або ім'я локальної папки, або URL-адреса http/https сценарію перевірки
• maintenanceModeType  - Тип режимуобслуговування (значення: ІММ/ПММ)
• verificationScriptTimeoutSec  - тайм-аут сценарію верифікації в секундах
• rebootTimeoutSec  - тайм-аут перезавантаження вузла в секундах

Зверніть увагу, що перед виконанням команди liaRunOsPatching слід спочатку авторизуватися і отримати конфігурацію системи, дивіться приклад нижче.
 

Приклад команди

* змінна token містить токен Keycloak, який був повернутий з /auth/login або з /api/gatewayLogin.
**ip-address - IP-адреса http сервера, що містить скрипти для виконання

Get json конфігурації системи, який буде корисним навантаженням команди patch (повинен замінити liaPassword і mdmPassword вручну з null на деякий рядок).


<>Вставте висновок цієї команди (з фіксованими паролями) у файл config.json:

curl -s -X POST -k -H  "Content-Type: application/json" -d '{ "mdmIps":["1.2.3.4","5.6,7,8"], "mdmUser":"<mdm_username>", "mdmPassword":"<mdm_password>", "securityConfiguration":{ "allowNonSecureCommunicationWithMdm":"true", "allowNonSecureCommunicationWithLia":"true", "disableNonMgmtComponentsAuth":"false" } }' -H "Authorization: Bearer ${token}"  https://<m&o-ip-address>/im/types/Configuration/instances

Виконайте команду patch:

curl -v -k -X -i POST -H "Content-Type:application/json" -H "Authorization: Bearer ${token}" 

 "https:/<m&o-ip-address>/im/types/Configuration/actions/liaRunOsPatching?executeOnAllSdss=true &isRebootRequired=true&isVerificationScriptRequired=true&patchScriptFilePath=https://<ip-address>/patch_script&verificationScriptFilePath=https://<ip-address>/verification_script&maintenanceModeType=IMM&rebootTimeoutSec=30" -d @config.json

Журнали

Шлюз:

• /opt/emc/scaleio/gateway/logs/scaleio.log
• /opt/emc/scaleio/gateway/logs/scaleio-trace.log

ЛІЯ:
/opt/emc/scaleio/lia/logs/trc.x

Кінчик- Спеціальний перемикач для утримання скрипта у вузлі під час усунення несправностей або тестування:

• Редагувати файл /opt/emc/scaleio/gateway/webapps/ROOT/WEB-INF/classes/gatewayInternal.properties
• Знайдіть поле "ospatching.delete.scripts=false"
• Змініть на true для усунення несправностей (за замовчуванням false)