ServiceDesk MSP, ServiceDesk Plus, , , , , ,

Jednymi z największych minusów ServiceDesk Plus są brak możliwości uruchomienia Load Balancingu oraz bardzo dziwnie skonstruowana (i dodatkowo płatna) opcja FOS (Fail Over Service).  Jak to działa?

Jak działa FOS w SDP?

Producent umożliwia zakup usługi Fail Over dla ServiceDesk Plus. Opcja ta jednak ma spory minus – daje nam tylko możliwość zapewnienia Fail Over dla aplikacji. Wymaga ona dodatkowo umieszczenia załączników do zgłoszeń na zewnętrznym zasobie oraz umieszczenia bazy danych na zewnętrznym serwerze DB. Jak to dokładniej działa? Po zainstalowaniu dwóch aplikacji (Primary i Secondary) ServiceDesk Plus oraz skonfigurowaniu usługi FOS mamy tak na prawdę jeden działający serwer (Primary) i serwer uśpiony (Secondary). Ten drugi serwer sprawdza okresowo czy serwer Primary działa. Jeśli nie  – „przejmuje rolę” serwera Primary i pozwala użytkownikom na logowanie i pracę. Jednak usługa ta nie zda się na nic jeśli awarii ulegnie serwer DB lub serwer, na którym składujemy załączniki do zgłoszeń. O ile w przypadku awarii serwera z załącznikami jesteśmy w stanie zapewnić jakąkolwiek ciągłość działania o tyle w przypadku awarii serwera DB mamy sytuację krytyczną.

Padł serwer DB – przestajemy działać?

Większość organizacji korzystających z ServiceDesk Plus nie może sobie pozwolić nawet na kilkominutową przerwę w działaniu. Mimo posiadania licencji na Fail Over Service organizacje te muszą szukać dodatkowych rozwiązań.

Jednym z takich rozwiązań jest MSSQL Always On Availability Groups. W skrócie jest to grupa serwerów MSSQL działających jako klaster wysokiej dostępności. Co to daje? W przypadku awarii jednego serwerów DB działamy dalej! Jego rolę przejmuje inny serwer z klastra.

Posiadając już zbudowany klaster serwerów sprawa wydaje się prosta – otwieramy Admin Guide i widzimy, że powinniśmy uruchomić skrypt changedbserver.bat, podać dane do serwera (w naszym przypadku Listenera) a następnie kliknąć zapisz. Wszystko wydaje się, że poszło dobrze – aż do pierwszej awarii. Dlaczego?

Jeśli uruchamiamy skrypt changedbserver.bat uruchamia nam się ładny formularz, w którym wprowadzamy dane. Wydaje się, że wpisaliśmy poprawne dane do Listenera, klikamy Test. Ale chwila… Przyjrzyjmy się temu co widzimy w tym formularzu? W formularzu parametry Listenera zmieniły się na dane jednego z serwerów z klastra. I nic nie da się z tym zrobić – możemy znów zmienić dane a po kliknięciu Save znów mamy parametry jednego z serwerów.

Rozwiązanie tej sytuacji jest dość banalne. Musimy użyć tego, co fani Linuxa lubią najbardziej – trybu konsolowego :). W tym celu należy uruchomić (jako admin – tak dla przypomnienia) cmd. Następnie przechodzimy do katalogu ze skryptem changedb.bat który znajduje się w SDP_HOME/bin – w naszym przypadku jest to D:/ManageEngine/ServiceDesk/bin

cd D:\ManageEngine\ServiceDesk\bin
d:

Dalej uruchamiany skrypt changedbserver.bat – ale tutaj musimy uruchomić go w konsoli. W tym celu odpalamy changedb.bat z parametrem -console

changedbserver.bat --console

I tutaj dochodzimy do momentu, w którym nasza praca może zostać przerwana błędem. W konsoli widzimy:


D:\ManageEngine\ServiceDesk\bin>changeDBServer.bat -console
"========================================================"
""
"Usage : changeDBServer.bat --console [for non GUI user]"
"Usage : changeDBServer.bat [for GUI user]"
""
"========================================================"
cze 15, 2016 5:19:13 PM com.adventnet.servicedesk.server.utils.SDDataManager
INFO: rootDir :: D:\ManageEngine\ServiceDesk\bin\..\
cze 15, 2016 5:19:14 PM com.adventnet.servicedesk.server.utils.SDDataManager 
INFO: netutilsData :: {RELEASE={version=9.2}, BUILD={number=9209}}
cze 15, 2016 5:19:14 PM com.adventnet.servicedesk.server.utils.SDDataManager <init>
INFO: rebrandData :: {ADSELFSERVICE={name=ADSelfService Plus}, OPMANAGER={name=O
pManager}, PRODUCT={name=ManageEngine ServiceDesk Plus}, ADMANAGER={name=ADManag
er Plus}}
D:\ManageEngine\ServiceDesk\bin>changeDBServer.bat --console
"========================================================"
""
"Usage : changeDBServer.bat --console[for non GUI user]"
"Usage : changeDBServer.bat [for GUI user]"
""
"========================================================"
cze 15, 2016 5:19:19 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: rootDir :: D:\ManageEngine\ServiceDesk\bin\..\
cze 15, 2016 5:19:19 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: netutilsData :: {RELEASE={version=9.2}, BUILD={number=9209}}
cze 15, 2016 5:19:19 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: rebrandData :: {ADSELFSERVICE={name=ADSelfService Plus}, OPMANAGER={name=O
pManager}, PRODUCT={name=ManageEngine ServiceDesk Plus}, ADMANAGER={name=ADManag
er Plus}}
requestScheme is https
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lo
gging/LogFactory
at org.apache.commons.httpclient.HttpClient.<clinit>(HttpClient.java:65)

at com.adventnet.servicedesk.server.utils.SDClientUtil.isServerAlreadyRu
nning(SDClientUtil.java:179)
at com.adventnet.servicedesk.tools.ChangeDBServer.update(ChangeDBServer.
java:356)
at com.adventnet.servicedesk.tools.ChangeDBServer.main(ChangeDBServer.ja
va:65)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFacto
ry
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 4 more
D:\ManageEngine\ServiceDesk\bin>

Na pierwszy rzut oka widać błąd LogFactor’a. Zapewne teraz myślisz, że jest to błąd nie do przeskoczenia – nie ma definicji klasy. Problem leży jednakże całkowicie w innym miejscu. Przyczyną tego błędu jest włączony na naszym webserwerze SSL (https). Co teraz? Procedura trochę się wydłuża. Ale dla wprawionego administratora są to dodatkowe 2-3 minuty pracy.

Aby rozwiązać powyższy problem musimy „wykonfigurować” SSL i zmusić nasz webserwer do pracy po http. W tym celu uruchamiamy skrypt changewebserverport.bat jako parametry podając port, którego chcemy użyć oraz protokół (http). W naszym przypadku jest to:

D:\ManageEngine\ServiceDesk\bin>changeWebServerPort.bat 80 http

Jeśli wszystko poszło prawidłowo to w konsoli widzimy:

cze 15, 2016 5:29:20 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: rootDir :: D:\ManageEngine\ServiceDesk\bin\..\
cze 15, 2016 5:29:20 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: netutilsData :: {RELEASE={version=9.2}, BUILD={number=9209}}
cze 15, 2016 5:29:20 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: rebrandData :: {ADSELFSERVICE={name=ADSelfService Plus}, OPMANAGER={name=O
pManager}, PRODUCT={name=ManageEngine ServiceDesk Plus}, ADMANAGER={name=ADManag
er Plus}}

WARNING: Changes in webserver port and protocol should be updated in the agents
if agent mode is used for scanning Windows machines.
Procedure for updating these details in the agent is available under Admin tab -
-> Agent Settings --> Help card.


 Web Server Port set as 80, Web Server configured to support HTTP protocol.

Wracamy do skryptu changedbserver.bat. Tym razem już możemy przechodzić do konfiguracji klastra. Znów uruchamiamy skrypt z parametrem –console, Widzimy

"
"Usage : changeDBServer.bat [for GUI user]"
""
"========================================================"
cze 15, 2016 5:36:38 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: rootDir :: D:\ManageEngine\ServiceDesk\bin\..\
cze 15, 2016 5:36:38 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: netutilsData :: {RELEASE={version=9.2}, BUILD={number=9209}}
cze 15, 2016 5:36:38 PM com.adventnet.servicedesk.server.utils.SDDataManager <in
it>
INFO: rebrandData :: {ADSELFSERVICE={name=ADSelfService Plus}, OPMANAGER={name=O
pManager}, PRODUCT={name=ManageEngine ServiceDesk Plus}, ADMANAGER={name=ADManag
er Plus}}
requestScheme is http
************************************************************
DB Server Setup wizard
************************************************************

1) Setup POSTGRESQL Server
2) Setup MYSQL Server
3) Setup MSSQL Server
4) Quit
Go to [1/2/3/4] :

Wybieramy opcję numer 3 i rozpoczynamy konfigurację. Każdy parametr podajemy w osobnej linii. W naszym przypadku konfiguracja wygląda następująco:


     Host : sgllistener.local
     Port : 1433
     User : testsd9209
 Password : -----------
 DB Name : testsd9209

Jeśli wszystko poszło prawidłowo powinniśmy otrzymać informację:


MS SQl Sever configuration added successfully.

Teraz musimy ponownie przestawić nasz webserver na protokół https i ponownie skonfigurować connector. Opis czynności można znaleźć w Admin Guide.

Po przywróceniu SSL i uruchomieniu ServiceDesk możemy cieszyć się ze skonfigurowania MSSQL Always On Availability Group.