Kleine wijziging met grote gevolgen
Vandaag was het plan om dag lekker te werken aan het mooie OpenER project, helaas Murphy hier anders over te denken. Door systeembeheer werd een regel aan de firewal van de Blackboard database server toegevoegd. Niet heel bijzonder zou je denken en dat is het normaal ook niet. Helaas dacht IP Filter hier anders over en werden alle poorten dichtgegooid. Natuurlijk vanwege wat wisselingen zat de server niet op de console server aangesloten en was het dus nodig dat er iemand naar de serverruimte toeging om rechtstreeks op de server te kijken. Na enige tijd konden we weer remote bij de server, maar door de firewall waren de iSCSI verbindingen verbroken (gedeelte van de database bestanden staat op het SAN). Oracle kan hier heel slecht tegen en laat zich dan eigenlijk niet meer killen. Een reboot was noodzakelijk. Na het opnieuw opstarten bleek dat een aantal database files corrupt was geraakt. Omdat een restore wel te lang duurt, hebben we de procedure om de primary en secondary server te switch opgestart. Deze procedure bleek goed te werken, alleen bij het opnieuw opstarten van de applicatieservers (maar 3 van de 7) was de load-balancer ff wat in de war, waardoor het voor sommige gebruikers er langer niet op konden dan anderen. De switch-over van de load-balancer werkte gelukkig wel goed en daarmee was het probleem opgelost.
Uiteindelijk is Blackboard hierdoor van iets na half 11 tot half 2 niet beschikbaar geweest en dat tijdens de tentamenperiode!
Een van de zaken die we al wisten, maar die tot-nu-toe geen prioriteit hebben gekregen was dat de secondary database server een stuk kleiner is (12 t.o.v. 4 processoren en 36 t.ov. 4 GB geheugen). Volgens sommigen zou dit geen probleem zijn, maar als snel werd duidelijk het dit wel was. De load op de database ging naar 24 en dat is toch vrij veel. Vervolgens heb ik het grootste gedeelte van de portal gedisabled en daalde de load naar acceptabele waarden.
Vanavond wordt er een restore op de grote database server uitgevoerd en morgenochtend vroeg schakelen we weer terug en kan ik weer alles activeren. Uiteindelijk hebben we hier natuurlijk wel weer wat van geleerd:
- de procedure van switchen naar failover database werkt (deze was nog nooit in productie uitgevoerd).
- de fall-over database is duidelijk te klein en moet hoognodig vervangen worden (de urgentie hiervoor is nu dus ook duidelijk).
- het niet gebruiken van Blackboard als portal scheelt een heleboel database load.
- we hebben een goed team van mensen om de zaak weer op te lossen.
No feedback yet
Form is loading...