1 260
szerkesztés
Módosítások
a
→Adminisztrációs feladatok: heading javitas megint
A Shibboleth IdP-ben a következő adatok klaszterezését kell megvalósítani: artifact, session, replay, transientId, loginContext. Ezeket az adatokat a Shibboleth StorageService tárolja.
A Terracotta telepítéséhez és beállításához [https://spaceswiki.internet2shibboleth.edunet/confluence/display/SHIB2/IdPCluster ez a wikioldal] nyújt segítséget.
# Terracotta letöltése, kicsomagolása
sleep 5
if check_stopped; then
log_progress_msg "(cleaning persistent store)"
rm -r /var/lib/terracotta/server/*
log_end_msg 0
else
env.jmxurl service:jmx:rmi:///jndi/rmi://localhost:8083/jmxrmi
</source>
== Terracotta 2.7.3 ismert hibák ==
=== Log file flood ===
Az L2 újracsatlakozás engedélyezése esetén egy elvesztett kapcsolat után hiába áll helyre a helyes működés, a szerver szemetel a logba:
2009-06-24 14:48:38,304 [ConnectionEstablisher] WARN com.tc.net.protocol.transport.ClientMessageTransport -
ConnectionID(0.0e84473d1e744f4db1d539db88633a30): Timeout of 10000 milliseconds occured
2009-06-24 14:48:39,305 [ConnectionEstablisher] INFO com.tc.net.protocol.transport.ClientMessageTransport -
ConnectionID(0.0e84473d1e744f4db1d539db88633a30): Attaching new connection: [...]
Ez egy ismert probléma: http://jira.terracotta.org/jira/browse/CDV-1252 a javítás elkészült, azonban a 2.7.3 -ba még nem került be.
Workaround-ként ki lehet kapcsolni az l2 újracsatlakozást a konfigurációban. Ilyenkor azonban rövid hálózati megszakadás is teljes node újraindítást fog okozni.
== Terracotta 3.2.1 ismert hibák ==
Még nincs :)
== Troubleshooting ==
* Mindig ellenőrizni kell a logfájlokat! Ha egy szerver folyton írja a logfájlját, az általában rossz jel és elárvult kliensre utal ("Could not find communication stack..." üzenet).
* A teljes klaszter újraindítása után kötelező újraindítani a klienseket (Tomcat), ugyanis a Terracotta nem fogja engedni újra csatlakozni. Ezt egyébként a szerver logfájlban jelzi is.
* Nem érdemes egyszerre indítani a két Terracotta szervert, annak könnyen összeakadás lehet a vége, ha nem tudnak dönteni egymás között.
** ilyenkor az egyik szerver felszólítja a másik szervert a megállásra, ilyenkor azonban a diszken tárolt állapot megmarad, amit egy start parancs kiadása után nem hajlandó felhasználni a szerver processz.
** a megoldás az initszkript 'restart' parancsa (vagy két egymás utáni start, ugyanis második kísérletre már hajlandó elindulni 'dirty' adatokkal is).
* Az <code>/etc/nagios/check_terracotta --verbose</code> parancs a teljes klaszter állapotát visszaadja (szerverek és kliensek is).
* Ha egy probléma nem oldható meg csak az egyik szerver és a kliensek újraindításával, akkor a teljes klasztert újra kell indítani: mindkét szerver leállítása és a perzisztens adatok gondos törlése után egyesével újraindíthatóak a szerverek majd az aktív szerver indulása után a kliensek (Tomcat).
=== Kliens library ===
* a Tomcat webkonténerben fut
* a <code>/var/log/terracotta/client/log*/terracotta-client.log</code> fájlba logol
* '''JVM váltáskor, frissítéskor újra kell generálni!''' Ezt a <code>/usr/local/terracotta/bin/make-boot-jar.sh</code> szkripttel lehet megtenni, előtte törölni kell a <code>/usr/local/terracotta/lib/dso-boot</code> könyvtár tartalmát.
=== Szerver processz ===
* külön processzként fut
* a <code>/var/log/terracotta/server/log*/terracotta-server.log</code> fájlba logol
* a <code>/var/lib/terracotta/server/</code> könyvtárban tárol saját adatokat, amit kézzel történő tiszta újraindítás előtt törölni kell
=== Nagios riasztások és megoldásuk ===
* Túl kevés a kliens (client count is xxx)
** '''OK''': a Tomcat kliens megállt vagy megszakadt a kommunikáció a szerverrel.
** '''Megoldás''': a kliens listában nem szereplő Tomcat-et újra kell indítani.
* Nincs passzív node (not enough passive node)
** '''OK''': az egyik Terracotta szerver épp adatot szinkronizál a másiktól és ezért <code>passive-uninitialized</code> állapotban van.
** '''Megoldás''': pár percet érdemes várni, amíg a szinkronizáció befejeződik. Ha nem oldódik meg a probléma magától, akkor újra kell indítani a Terracotta szerver processzt.
* Nem elérhető egy node (node xxx is down)
** '''OK''': az egyik Terracotta szerver nem elérhető.
** '''Megoldás''': újra kell indítani.
= Adminisztrációs feladatok =
== JVM frissítése ==
A következő leírás meglehetősen az NIIF Intézet saját infrastruktúrájára specifikus, de talán más környezetekben is felhasználható.
=== Lépések összefoglalása ===
# Terheléselosztóból a frissítendő node-ot kivenni
# Tomcat, Terracotta leállítása a frissítendő node-on
# JVM beállítások (<code>/etc/java-6-openjdk/security</code>, ill. esetleg <code>/usr/lib/jvm/java-6-openjdk/jre/lib/security</code>) elmentése. Ez fontos azért, mert bizonyos JVM upgrade-ek (legalábbis a múltban) felülírták a tanúsítvány tárat, és ez nehezen javítható hibához vezetett (pl. az LDAP-hoz nem tudott kapcsolódni az IdP)
# JVM frissítés
# Boot jar generálás
# (Ha megváltozott a jar): Tomcat konfigban a boot jar átírása az újra
# Ellenőrzés, hogy megváltozott-e a cacerts ($JAVA_HOME/lib/security/cacerts). Ha igen, akkor írjuk felül az elmentett változattal
# Terracotta, '''majd utána''' Tomcat indítás
# (Az LVS magától visszateszi a megjavuló klaszter node-ot, de erről nem árt meggyőződni)
=== Shell parancsok ===
ldir2:~# ipvsadm -d -t idp.niif.hu:8443 -r idp1.aai.niif.hu:8443
ldir2:~# ipvsadm -d -t idp.niif.hu:https -r idp1.aai.niif.hu:https
ldir2:~# watch "ipvsadm -L -t idp.niif.hu:https && ipvsadm -L -t idp.niif.hu:8443"
idp1:~$ sudo /etc/init.d/tomcat6 stop
idp1:~$ sudo /etc/init.d/terracotta stop
idp1:~$ tar czf security.tgz /etc/java-6-openjdk/security
idp1:~$ sudo aptitude safe-upgrade
idp1:~$ sudo env JAVA_HOME=/usr/lib/jvm/java-6-openjdk /usr/local/terracotta/platform/bin/make-boot-jar.sh \
-f /etc/shibboleth-idp/tc-config.xml
idp1:~$ sudo vim /etc/default/tomcat6
idp1:~$ sudo /etc/init.d/terracotta start
idp1:~$ sudo /etc/init.d/tomcat6 start
