I vilken ordning ska man starta olika eNova-komponenter?
Så här:
- BusinessService
- Övriga windowsservicar (4See, Integration, NewsLetter, Publishing, Search, …), Website node #1.
- Website node #2, Website node #3, Website node #4, …
Eftersom:
- Man vill att BusinessServicen ska vara masternoden. Det är inget krav, men best practice.
- När websiter har sync=true (Enova.Site.Synchronizer.UseSynchronizer, value=”True”) i web.config synkar webnoder in systemtexter och cms actions som de bland annat läst in med reflection från dller. De skrivs in i databasen. Endast 1 webnode ska ha sync=true, men råkar man sätta den till true på flera webservrar, tex vid kopiering av web.config, så är eNova tyvärr inte race condition-free vid uppstart, riskerar då att synka in saker inläst från websiter flera gånger om. Duplicerad data i databasen leder normalt inte till några direkta showstoppers för eNova men försvårar administration.
Ok då. Men i vilken ordning ska man stoppa olika eNova-komponenter? Spelar det över huvud taget någon roll i vilken ordning man stoppar dem? Problemen med felaktig ordning vid avstängning är mer subtila, och i de flesta fall är eventuella problem beroende av många omständigheter som inte alltid är relevana för ens egen miljö. Tumregeln som är snyggast är förstås att stoppa allt i omvänd ordning som det startades upp. Primärt eftersom vissa servicar är beroende av business servicen. Det kan alltså förhindra att servicar som är beroende av businesservicen kraschar.
Så, i värsta fall, bara ett litet eventuellt kraschfel i logfilen om man stoppar i fel ordning? Ja – om man har en defaultinstallation av windowsservicar. Ja – om man inte har någon övervakning av windowsservicar. Om man däremot valt att ändra inställningar på windowsservicar, till ”Recover = Restart the Service”, så kommer servicar som är beroende av businesservicen startas om vid krasch. Och det vill man ju inte.
Men spelar det egentligen någon roll om en service kraschar om och om igen? Ja, och nu till det extremt lömska felet som jag stötte på.
Vi hade ett deployscript. Det stoppade först businesservicen, och sen publishingservicen. Pseudokoden för scriptet såg ut så här:
if(bs.status!=stopped)
stop-service ”eNova bs”
if(publishing.status!=stopped)
stop-service ”eNova publishing”
copy files
Ser du felet? När den andra if-satsen körs, så kan publishingservicen vara kraschad. Kort därefter startas den upp igen av windows servicehanterare! Det orsakade att deployscriptet efteråt inte kunde ersätta publishingservicens filer. Lömskt som sagt, det hände bara ibland pga race-conditions, men gick att lista ut efter lite studerande av event viewer, i kombination med att lägga märke till att någon ändrat defaultbeteende vid krasch, till att windows servicehanterare ska starta om servicar.
Kontentan: Om du har någon service-watchdog, dvs windows servicehanterare, som startar om servicar när de kraschar, då måste man stänga av servicar i rätt ordning. Annars är det risk för race conditions när man kontrollerar om en service är avstängd.
Postat i:Enova Dokumentation, Tips & Verktyg
