| Управление на външни процеси чрез OPMN |
| Сряда, 01 Октомври 2008 17:03 |
|
Инсталацията на Oracle Application Server Enterprise Edition, която ползвам в момента има три логически части в архитектурата си. Първо – инфраструктура (Metadata Repository и Identity Management), второ – Oracle Portal и трето, колкото и да ми е неприятно – един независим OC4J контейнер (OC4J 10.1.3.4). Ролята на този контейнер е върху него да работят набор портлети, които се визуализират в портала. Той работи на същата машина, на която е Oracle Portal, но двете неща са инсталирани в отделни директории. Oracle Portal се намира в c:\oraportal, а OC4J в c:\oc4j.
Когато сървърът се рестартира Oracle Process Manager and Notification Server-ът (OPMN) стартира автоматично всички процеси на портала. Нещо повече – ако някой от процесите на портала забие, OPMN автоматично го рестартира и така гарантира поне в някаква степен, че порталът е жив. Не така стоят нещата обаче със самостоятелния OC4J. Него нито има кой да го стартира, нито има кой да го наблюдава. Ако сървърът бъде рестартиран, някой администратор трябва ръчно да го пусне (чрез c:\oc4j\bin\oc4j.cmd). Нещо повече, тъй като самият портал ще се вдигне първи, то потребителите ще виждат една частично работеща система (по-конкретно полу-празни страници и региони за портлети с грешки в тях). Тъй като не ми се искаше да се стига до подобни резултати първото, което ми хрумна е да представя OC4J като service на операционната система и тя да се грижи за неговото стартиране. Естествено оказа се, че за пореден път надценявам Windows. Въпреки, че в Resource Kit-а му има някакъв инструмент който регистрира външни програми като service-и, то той е изключително базов. Даже няма начин да му се зададе как да гаси процеса, което направо си е абсурдно (нито ме устройва загасен service с работещ OC4J, нито пък директно терминиран процес на OC4J). След известен размисъл ме осени идеята, че няма смисъл да преоткривам колелото. В крайна сметка на самият сървър имам работеща цялостна система за наблюдение и управление на процеси, а именно – самият OPMN. Колко трудно ще е той да поеме грижата за още един допълнителен, пък макар и външен за портала процес? Оказа се, че изобщо не е трудно. Техниката, която ще опиша тук е конкретно за OC4J, но съвсем спокойно може да се ползва и за всякакъв друг външен процес, който искаме OPMN да управлява. И така... Главният конфигурационен файл на OPMN е opmn.xml и в конкретната инсталация беше разположен в c:\oraportal\opmn\conf. В самото му начало се задава зареждане на ред модули, които после управляват описаните по-долу процеси. Това, което ми беше нужно е частта: <module path="$ORACLE_HOME\opmn\lib\libopmncustom"> <module-id id="CUSTOM"> </module-id> </module> В нея се описва модулът за управление на външни процеси. Добавих един допълнителен ред за нов външен процес, който кръстих OC4JStandalone. <module path="$ORACLE_HOME\opmn\lib\libopmncustom"> <module-id id="CUSTOM"/> <module-id id="OC4JStandalone" /> </module> Към края на файла и преди тагът </ias-instance>, който маркира края на секцията с параметри за процесите добавих следния запис, който пък описва моя процес OC4JStandalone: <ias-component id="OC4JStandalone" status="enabled" id-matching="false"> <environment> <variable id="ORACLE_HOME" value="c:\oc4j" append="false"/> <variable id="JAVA_HOME" value="C:\Program Files\Java\jdk1.6.0_10" append="false"/> </environment> <process-type id="OC4JStandalone" module-id="OC4JStandalone" working-dir="c:\oc4j"> <process-set id="OC4JStandalone" restart-on-death="true" numprocs="1"> <module-data> <category id="start-parameters"> <data id="start-executable" value="%JAVA_HOME%\bin\java" /> <data id="start-args" value="-jar c:\oc4j\j2ee\home\oc4j.jar -config c:\oc4j\j2ee\home\config\server.xml" /> </category> <category id="stop-parameters"> <data id="stop-executable" value="%JAVA_HOME%\bin\java" /> <data id="stop-args" value="-jar c:\oc4j\j2ee\home\admin.jar ormi://localhost:23791 oc4jadmin welcome1 -shutdown" /> </category> <category id="ping-parameters"> <data id="ping-type" value="http" /> <data id="ping-url" value="/em" /> <data id="ping-host" value="localhost" /> <data id="ping-port" value="8888" /> <data id="ping-limit" value="3" /> <data id="ping-timeout" value="300" /> </category> <category id="ready-parameters"> <data id="use-ping-for-ready" value="false" /> </category> </module-data> </process-set> </process-type> </ias-component> Нека коментираме конфигурацията. Секцията <environment> позволява да дефинираме променливи от обкръжението, специфични за процеса. Единствените ми нужни за OC4J са ORACLE_HOME (който е различен от този на портала) и JAVA_HOME. Имайте предвид, че в случая използвам JDK 1.6.0, което към писането на този материал не е сертифицирано с OC4J. Аз го ползвам за тестови цели и ще го върна на 1.5 на по-късен етап. Иначе описаната конфигурация изпробвах и с 1.5 и работи нормално. При описанието на самия процес най-важните параметри са работната директория (working-dir), която насочвам към c:\oc4j и инструкциите към OPMN да рестартира процеса, ако той забие (restart-on-death). Следващите важни параметри са в двете категории start-parameters и stop-parameters. Там описваме как OPMN да стартира и респективно – да спре процеса. И в двата случая караме OPMN да извиква Java, като в първия случай и предаваме oc4j.jar и конфигурационния му файл server.xml, което на практика стартира OC4J. В случая, когато трябва да го спрем използваме административния интерфейс, намиращ се в admin.jar, като му задаваме команда за OC4J shutdown, насочена към локалната машина. Разделът ping-parameters съдържа информация, по която OPMN да разбере, че процесът оперира нормално. В случая го карам да извършва ping към http://localhost:8888/em, което е адресът на административната конзола на OC4J. Тя не е отделен процес както при Application Server, а тръгва и спира заедно със самия OC4J, така че е напълно подходяща за случая. Стойността ping-limit задава при колко пропуснати отговора от процеса OPMN да го брои за увиснал, а ping-timeout – максималното време в секунди, в което процесът трябва да отговори на ping. След като сме конфигурирали процеса в opmn.xml, трябва да накараме OPMN да зареди новата конфигурация. Това става по следния начин: C:\oraportal\opmn\bin>opmnctl reload opmnctl: reconfiguring opmn... opmnctl: opmn reloaded successfully. C:\oraportal\opmn\bin> Изпълняваме opmnctl stopall, за да изключим всички работещи процеси към момента, след което изпълняваме opmnctl startall: C:\oraportal\opmn\bin>opmnctl startall opmnctl: starting opmn and all managed processes... C:\oraportal\opmn\bin> Бърз поглед върху работещите процеси изглежда така: C:\oraportal\opmn\bin>opmnctl status Processes in Instance: -------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- DSA | DSA | N/A | Down LogLoader | logloaderd | N/A | Down dcm-daemon | dcm-daemon | N/A | Down OC4J | home | 4748 | Alive OC4J | OC4J_Portal | 3748 | Alive OC4J | ForumOC4J | 5724 | Alive WebCache | WebCache | 4300 | Alive WebCache | WebCacheAdmin | 2684 | Alive HTTP_Server | HTTP_Server | 5680 | Alive OC4JStandalone | OC4JStandalone | 4652 | Alive За да проверя дали OPMN наистина наблюдава OC4J, отоворих нова конзола и ръчно подадох команда за изключване към OC4J. C:\oc4j\bin>oc4j -shutdown -port 23791 -password welcome1 Shutdown OC4J instance... C:\oc4j\bin> През това време продължих да наблюдавам процесите чрез opmnctl. Почти мигновенно OC4JStandalone смени статуса си: C:\oraportal\opmn\bin>opmnctl status Processes in Instance: -------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- DSA | DSA | N/A | Down LogLoader | logloaderd | N/A | Down dcm-daemon | dcm-daemon | N/A | Down OC4J | home | 4748 | Alive OC4J | OC4J_Portal | 3748 | Alive OC4J | ForumOC4J | 5724 | Alive WebCache | WebCache | 4300 | Alive WebCache | WebCacheAdmin | 2684 | Alive HTTP_Server | HTTP_Server | 5680 | Alive OC4JStandalone | OC4JStandalone | 4652 | Stopped Още следващото изпълнение на opmnctl показа, че OPMN се е заел със "съживяването" на процеса: C:\oraportal\opmn\bin>opmnctl status Processes in Instance: -------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- DSA | DSA | N/A | Down LogLoader | logloaderd | N/A | Down dcm-daemon | dcm-daemon | N/A | Down OC4J | home | 4748 | Alive OC4J | OC4J_Portal | 3748 | Alive OC4J | ForumOC4J | 5724 | Alive WebCache | WebCache | 4300 | Alive WebCache | WebCacheAdmin | 2684 | Alive HTTP_Server | HTTP_Server | 5680 | Alive OC4JStandalone | OC4JStandalone | 4688 | Init Малко по-късно OC4JStandalone премина в Alive състояние, както и се очакваше. Да обобщим: Сравнително лесно можем да използваме OPMN, за да наблюдаваме и управляваме външни процеси. В този пример използвах основно базовите възможности на системата. Има доста конфигурационни параметри, с които да си поиграе човек. Включително и по-сложни проверки дали даден процес е жив. Обърнете внимание и на id-matching опцията, при описанието на процеса. Ако нейната стойност е true, OPMN няма да стартира процеса заедно с останалите процеси на инстанция. Външния процес ще трябва да стартирате ръчно, но от там нататък той ще бъде наблюдаван и рестартиран коректно. Подобно поведение има и LogLoader процесът, който по подразбиране също не се стартира. |
Коментари