Onderwerp: CLUSTER SPECIALISIST gezocht

Oorspronkelijk geplaatst door phreak

Zo weet je ook _zeker_ dat als een server down is, hij ook echt down is.

True, echter er zijn andere manieren om dit te controleren. Denk aan SMS systeem met een centrale database als controle of het werkelijk down is.

Je zou ook voor alle zekerheid de server handmatig kunnen laten recoveren na uitval of scripts schrijven om de huidige situatie te controleren en bij twijfel de systeembeheerders het besluit laten nemen of recovery noodzakelijk is.

Oorspronkelijk geplaatst door Swiftway-UK

True, echter er zijn andere manieren om dit te controleren. Denk aan SMS systeem met een centrale database als controle of het werkelijk down is.

Je zou ook voor alle zekerheid de server handmatig kunnen laten recoveren na uitval of scripts schrijven om de huidige situatie te controleren en bij twijfel de systeembeheerders het besluit laten nemen of recovery noodzakelijk is.

Wat als die database down is? Je moet niks uitsluiten door externe services te laten beinvloeden, de kans dat het down -kan- gaan, bestaat, ook al zet je er 100 servers neer, het _kan_ je kan beter kijken hoe je het risico het beste kunt minimaliseren.

Oorspronkelijk geplaatst door phreak

Wat als die database down is? Je moet niks uitsluiten door externe services te laten beinvloeden, de kans dat het down -kan- gaan, bestaat, ook al zet je er 100 servers neer, het _kan_ je kan beter kijken hoe je het risico het beste kunt minimaliseren.

Klopt helemaal, het systeem zou dan ook als volgt werken

Cluster met 2 systemen in replicatie

Systeem 1 DC1
Systeem 2 DC2

Theoretisch indien Systeem 1 geen contact meer krijgt met systeem 2, dan neemt systeem 1 aan dat systeem 2 down is. Terecht merk je op dat deze controle door de spreiding beinvloed kan worden door netwerkstoringen, waardoor de software verkeerde beslissingen gaat nemen.

Je kunt een extra check inbouwen

Systeem 1 DC1 + SMS via GSM
Systeem 2 DC2 + SMS via GSM

Nu checked het systeem niet alleen de uptime via de netwerkconnectie, maar maakt een extra controle door elkaar een SMS te sturen, waarna de serversoftware op deze SMS een response geeft.

Systeem 1 ----> netwerk -----> Systeem 2
GSM 1 ----> SMS -----> GSM 2

Bij geconstateerde downtime van systeem 2 door systeem 1 via het netwerk, stuurt Systeem 1 een SMS naar GSM 2 die verbonden is aan Systeem 2. Indien Systeem 2 nog steeds online is, dan volgt er een response via SMS dat het systeem aan de andere kant nog steeds beschikbaar is.

Je zou zelfs een programma kunnen schrijven op smartphones dat zelf beschikbaarheid checked en op basis daarvan opdrachten geeft aan je switches of APC power reboot switch of je servers of systeembeheerders, maar dat is dan weer een stapje verder.

Als 1 gateway down is, hoe kan hij communiceren dat het niet de server is maar de gateway en zo onnodige problemen veroorzaakt?

Ook replicaten is niet alles.. drdb heeft zich bewezen om buggy te zijn.

Oorspronkelijk geplaatst door phreak

Als 1 gateway down is, hoe kan hij communiceren dat het niet de server is maar de gateway en zo onnodige problemen veroorzaakt?

Via de GSM. Server is verbonden met de GSM via een datakabel, niet via het netwerk of via een SMS gateway.

Oorspronkelijk geplaatst door Swiftway-UK

Via de GSM. Server is verbonden met de GSM via een datakabel, niet via het netwerk of via een SMS gateway.

En als je geen bereik heb in het datacenter, of de sms heeft vertraging?

Oorspronkelijk geplaatst door phreak

En als je geen bereik heb in het datacenter, of de sms heeft vertraging?

Geen bereik in DC zou inderdaad een probleem opleveren.
SMS kun je ook zenden met ontvangstbevestiging, dus een dergelijke vertraging kun je rekening mee houden in de software die de reactie moet meten.

Je zou zoiets ook eventueel kunnen opzetten met ISDN lijnen natuurlijk, waar een server via ISDN contact zoekt met het andere netwerk.

Je maakt het allemaal veel moeilijker dan het hoeft te zijn, hou het op 1 locatie, en zorg dat de infra daar goed geregeld is, scheelt je ook nog eens een berg werk en onzekerheid of dat alles wel gaat werken.

Oorspronkelijk geplaatst door phreak

Je maakt het allemaal veel moeilijker dan het hoeft te zijn, hou het op 1 locatie, en zorg dat de infra daar goed geregeld is, scheelt je ook nog eens een berg werk en onzekerheid of dat alles wel gaat werken.

Ik geef ook de voorkeur aan clusteren op 1 locatie, echter zijn er klanten die perse globale spreiding nodig (denken te) hebben.

Is Plesk een harde eis? Met bijvoorbeeld DirectAdmin of een eigen systeem kunnen wij dit regelen (eventueel in 1 datacenter en 2 netwerken voor het geval 1 netwerk offline gaat).

Oorspronkelijk geplaatst door Swiftway-UK

Ik geef ook de voorkeur aan clusteren op 1 locatie, echter zijn er klanten die perse globale spreiding nodig (denken te) hebben.

mwa als een netwerkboer plat is
is het op zijn minst wel handig om troep extern te hebben

indien mogelijk dan een complete replica te hebben
door software of hardwarematig indien niet mogelijk
dat deze door bijvoorbeeld dns wijzigingen toch weer online te krijgen

Bedankt voor alle reacties.

Ik wil nu op korte termijn (lees om alles snel stabiel te krijgen) 2 servers herinstalleren.
Later wil ik als nog naar een HA en schaalbaar cluster toe, maar voor nu wil ik dit even zo oplossen.

Dit is mijn voorstel:

Server 1 in datacenter 1
Server 2 in datacenter 1

Als alles goed draait plaats ik een server naar een ander datacenter.
Ik wil de kans op storing zoveel mogelijk uitsluiten, dus ook in het datacenter.

Ik wil middels heartbeat failover kunnen laten plaatsvinden.
Vallen bepaalde services op server 1 uit, dan worden bepaalde services gestopt. De services op server 2 worden gestart. Alles is dan binnen no-time automatisch weer online.

Server 1 kan vervolgens gecontroleerd worden en dient vervolgens weer als faillover van server 2.

Middels drbd wil ik de dataopslag verwerken, als soort van Raid1 oplossing tussen de servers.

Monitoring doen we overigens met Nagios die kan ook via SMS meldingen doorgeven naar een storingsnummer.

Ik hoor graag wat jullie hiervan vinden.

Ik wil je wel even meegeven dat drdb nog erg buggy is, en het rebuilden > X grote je al heel snel in de problemen brengt!!!

Oorspronkelijk geplaatst door phreak

Ik wil je wel even meegeven dat drdb nog erg buggy is, en het rebuilden > X grote je al heel snel in de problemen brengt!!!

Heb je hiervoor betere / andere alternatieven ?
Delen andere forumleden deze mening?

Daarnaast moet je gaan kijken hoe je dat gaat doen met de database replica.