uit de serie "dagboek van een systeembeheerder"
auxilery server deel II
Het project is in zijn afrondingsfase. Ik heb alle scripts geschreven, de schijven gepartioneerd en alles gescheduled, er cronjobs voor gemaakt, zoals dat in de UNIX wereld heet.
Om het project nog even samen te vatten: de auxilery server is een server die de taken van de primary server kan overnemen zodra de laatste uitvalt. Dat is op zich niet zo bijzonder, zij het dat de auxilery in principe niet online is.
Eens per week wordt ie aangezet, waarbij hij volautomatisch alles synchroniseert met de primary. Niet helemaal alles, maar wel de noodzakelijke dingen om het netwerk door te laten draaien. Dat komt neer op in ieder geval de homedirectorys, dns, dhcp, ldap en security updates.
Mocht de primary het ergens halverwege de periode opgeven dan mis je wel een paar dagen. Maar die zijn niet verloren, omdat of de backups nog intact zijn, of de andere schijven. Of alle schijven zijn er nog, maar de primary is door andere oorzaken onderuit gegaan. Een paar dagen zijn echter niet fataal voor het laten doordraaien van het netwerk.
Omdat te kunnen doen moet de auxilery zich wat anders gaan gedragen op het netwerk als de primary afwezig is. Daarom zijn er twee modes waarin de auxilery zich kan bevinden, namelijk STANDBY of SERVICE.
In standbymode zal de auxilery updaten tijdens boottime en verder eens per etmaal op een vast tijdstip, als de auxilery tenminste aanstaat. In servicemode zal de auxilery zich voordoen alsof hij de primary is op het gebied van filesharing (nfs). Dit gebeurt door een kleine ingreep in de dns-database waarbij de verwijzingen van de canocinal names van de shares worden aangepast. Op het plaatje is een stukje van de code te zien die deze ingreep doet. Dit is ook toepasbaar voor bijvoorbeeld de webserver, maar die zit nog niet in het project.
Voor de andere services (dns,dhcp,ldap) is een dergelijke ingreep niet nodig. De werkstations weten al dat als de primary niet antwoordt ze de auxilery kunnen raadplegen.
Ik ga nog een white paper schrijven met deze oplossing als voorbeeld. Zoals ik al eerder zei, er zijn heel veel mogelijkheden voor redundancy, maar mijn offline model voor een auxilery ben ik eigenlijk nooit tegengekomen. Ik heb hiervoor gekozen omwille van energiebesparing. In mijn rijke tijd stookte ik de kilowatts er lustig doorheen, en was energiebesparing een hobby voor het geweten. Maar nu is het bittere noodzaak. Ik kan me voorstellen dat dit een toepassing kan hebben op alle plaatsen waar energiebesparing een issue is, ook bijvoorbeeld als de primary remote is en de auxilery op de site waar zuinig aan gedaan moet worden, zoals bijvoorbeeld op (ruimte)schepen, vakantiehuisjes of op de zuidpool.
ps. voor de oplettende lezertjes: mijn sed codering is inderdaad wat primitief. Maar het werkt wel :-D
auxilery server deel II
Om het project nog even samen te vatten: de auxilery server is een server die de taken van de primary server kan overnemen zodra de laatste uitvalt. Dat is op zich niet zo bijzonder, zij het dat de auxilery in principe niet online is.
Eens per week wordt ie aangezet, waarbij hij volautomatisch alles synchroniseert met de primary. Niet helemaal alles, maar wel de noodzakelijke dingen om het netwerk door te laten draaien. Dat komt neer op in ieder geval de homedirectorys, dns, dhcp, ldap en security updates.
Mocht de primary het ergens halverwege de periode opgeven dan mis je wel een paar dagen. Maar die zijn niet verloren, omdat of de backups nog intact zijn, of de andere schijven. Of alle schijven zijn er nog, maar de primary is door andere oorzaken onderuit gegaan. Een paar dagen zijn echter niet fataal voor het laten doordraaien van het netwerk.
Omdat te kunnen doen moet de auxilery zich wat anders gaan gedragen op het netwerk als de primary afwezig is. Daarom zijn er twee modes waarin de auxilery zich kan bevinden, namelijk STANDBY of SERVICE.
In standbymode zal de auxilery updaten tijdens boottime en verder eens per etmaal op een vast tijdstip, als de auxilery tenminste aanstaat. In servicemode zal de auxilery zich voordoen alsof hij de primary is op het gebied van filesharing (nfs). Dit gebeurt door een kleine ingreep in de dns-database waarbij de verwijzingen van de canocinal names van de shares worden aangepast. Op het plaatje is een stukje van de code te zien die deze ingreep doet. Dit is ook toepasbaar voor bijvoorbeeld de webserver, maar die zit nog niet in het project.
Voor de andere services (dns,dhcp,ldap) is een dergelijke ingreep niet nodig. De werkstations weten al dat als de primary niet antwoordt ze de auxilery kunnen raadplegen.
Ik ga nog een white paper schrijven met deze oplossing als voorbeeld. Zoals ik al eerder zei, er zijn heel veel mogelijkheden voor redundancy, maar mijn offline model voor een auxilery ben ik eigenlijk nooit tegengekomen. Ik heb hiervoor gekozen omwille van energiebesparing. In mijn rijke tijd stookte ik de kilowatts er lustig doorheen, en was energiebesparing een hobby voor het geweten. Maar nu is het bittere noodzaak. Ik kan me voorstellen dat dit een toepassing kan hebben op alle plaatsen waar energiebesparing een issue is, ook bijvoorbeeld als de primary remote is en de auxilery op de site waar zuinig aan gedaan moet worden, zoals bijvoorbeeld op (ruimte)schepen, vakantiehuisjes of op de zuidpool.
ps. voor de oplettende lezertjes: mijn sed codering is inderdaad wat primitief. Maar het werkt wel :-D
Reacties