HA, ami nem csak hardver para, hanem karbantartás ellen is véd

hasznalj vmware infrastructuret ;)

"Egy olyan HA megoldást keresek, ami kivédi a hardver eredetű parákat + ha software/kernel upgrade-re van szükség, azon is átsegít."

A legtobb (mindegyik?) HA-megoldas tudja ezt.

"De hogy valósítom meg azt, hogy ne csak az adat, hanem az azt kiszolgáló szoftverek + konfigurációik és egyéb dolgaik is szikronban legyenek, de ha upgrade-elni akarok, akkor külön tudjam választani a gépeket, aztán upgrade/reboot/stb után újra összacsatolhassam őket?"

Altalaban ellenjavalt, hogy az egyes node-ok configjai igy "szinkronban" legyenek, celszeru inkabb kezzel masolgatni/rsync-elni, ha szukseges (igy kisebb valoszinuseggel fog a hulyeseg elterjedni cluster-szerte).

Egyebkent a legtobb storage (meg pl. az lvm is) tud writable snapshotokat, az pont ilyenre jo.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Bevallom most linux alatt nem tudom ezt milyen eszközökkel lehetne megoldani ( sajna ilyen irányban nincs elég tapasztalatom ), de elméletileg ( sztem ) az alábbi linuxon is kivitelezhető lenne egy kis utánajárás után:

Van 2 géped, amelyek valamilyen HA megoldással ( heartbeat? ) össze vannak kötve.. Ezen vannak az alap operációs rendszerek, illetve az alkalmazások számára szükséges konfigurációs állományok, illetve a HA WAN felé kinéző IP-je ( amin az alkalmazásokat is elérhetik kívülről )
Van további 2 géped, ami vagy egy sima storage szerver, vagy akár egy clusterre épített filesystem, amit a 2 alap gép ugyan úgy lát ( ezen rendszerek elvileg elég ha csak folyamatosan szinkronizálják egymás között az adatokat, hogy az egyik elhalálozása esetén a másikra automatikusan át tudjanak állni a szervízt nyújtó szerverek )

Amennyiben valamiféle komolyabb upgrade tevékenység folytán az 1ik gépet "test"-nek akarod használni, úgy arra az időre a 2. szervízt nyújtó gépet ki lehet kapni a clusterből, megcsinálni rajta amit kell, majd ha minden sikerrel zárult, akkor a Cluster WAN IP-jét takeover-elni a másik gépre, és ugyan ezen módosításokat megcsinálni a másik szerveren is, majd a clustert ismét helyre állítani. Ha ügyesen csinálod akkor elméletileg szolgáltatás kiesés nem lehet ilyen alapon ( vagy ha gáz van akkor csak nagyon rövid kiesés, mert a még működő szerverre bármikor vissza lehet lőni a szolgáltatást, ha gázt észlel az ember ).

Amúgy a konfigurációs állományokat, illetve a start/stop/takeover scripteket ajánlatos a szerveken tényleg külön-külön kezelni, és egy upgrade utána alaposan letesztelni ismét mind ( ha van rá lehetőség ), nehogy egy olyan hiba okozzon inkonzisztenciát, vagy ne adj isten hibás takeover-t - valódi hiba esetén - , amit amúgy kis átgondolással meg lehetett volna előzni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Csinálsz egy production, meg egy teszt clustert, módosítani a teszt környezetben, és ha ott minden klappol, akkor megy a változás az élesre. Ugyanez igaz a frissítésekre is. Nem véletlen, hogy üzletileg kritikus rendszerek esetén a standardnak tekintett felállás három környezetet jelent: éles, teszt és fejlesztői, amiben a módosítások/állapotok mozgásának az iránya kötött: bármilyen módosítás először a teszten (ami valójában az aktuális éles rendszer mentésének a visszatöltéséből áll elő) történhet meg, és csak azt követően az élesen.