Budapest Sysadmin Meetup Failover Cluster 1x1. Gál Tamás. Cloud Infrastructure TSP Microsoft Magyarország

Átírás

1 Budapest Sysadmin Meetup Failover Cluster 1x1 Gál Tamás Cloud Infrastructure TSP Microsoft Magyarország

2 Windows Server Failover Cluster Magas rendelkezésre állás Megengedhető kiesés / év 99% 99,9% 99,99% 99,999% 3 nap 15 óra 36 perc 8 óra 45 perc 36 mp. 52 perc 33 mp. 5 perc 15 mp.

3

4 Szolgáltatás többszörözése Virtualizációs réteg alkalmazása Fürtözés

5 Failover Cluster Magas rendelkezésre állás Hardver HA

6 Fizikai szerver UCS B200 M3! Console Reset UCS B200 M3! Console Reset UCS B200 M3! Console Reset

7 Támogatott tárolási megoldások iscsi SAS Serial Attached SCSI FCoE Fiber Channel over Ethernet SMB v3.x A WS12 óta Fiber Channel (FC) shared *.vhdx A WS12R2 óta Storage Spaces

8

9

10

11

12 MEMORY Modified Configuration Memory memory content data pages IP connection iscsi, FC or SMB Storage

13 Configuration State

14

15

16 Scale up... Scale out...

17 Stabilabb OS Kisebb támadási felület A WS12 óta van járható, oda-vissza út a Server Core és full UI között, újratelepítés nélkül is.

18

19

20

21

22 Szavazási modell a vállalható működés biztosítására Lehetséges szavazók: a fürttagok (mindegyik) + 1 tanúlemez (lemez vagy fájlmegosztás) Korábban 3-4 quorum típus, a WS12R2 óta dinamikus (az aktuális fürttagságtól függ, mindig páratlan) Teljesen automatikus működés De meg is tudjuk nézni, hogy áll: (Get- Cluster).WitnessDynamicWeight Cluster Dynamic Quorum Configuration

23 Integrált frissítési megoldás a fürtök számára Az új frissítéseket észleli és a szerverterheléseket az adott tagról egy másikra terheli a frissítés idejére Kevesebb szerverleállás a fürt tagok frissítésének koordinálásával Teljesen automatizálható, nincs emberi tényező Windows Update Agent és / vagy külső bővítmények segítségével működik Kétfajta üzemmód: helyi és távoli U Current Workload Third-party plug-in for updates Application Client Windows Server Cluster

24 A fontosabb virtuális gépek költözés esetén mindenképpen elindulnak Ha nincs elég erőforrás, akkor az alacsonyabb prioritású gépek automatikusan leállnak vagy mentett állapotba kerülnek A lekapcsolt gépeket a rendszer ciklikusan megpróbálja ismételten elindítani Node hiba! Nincs elég memória! Sikeres VM indítás Az alacsonyabb prioritású virtuális gépek leállíthatóak

25 Alkalmazások ellenőrzése - a VM-eken belül Bármilyen rendszerszolgáltatást lehetséges monitorozni (WS, SQL, Exchange, stb. is), a VM-en kívülről Ha megáll, egy szolgáltatás újraindítás következik 3 egymás utáni hiba után a cluster egy bejegyzést tesz az eseménynaplóba (ID 1250) VM állapota Application Critical -ra változik és újra is indulhat automatikusan Ha nincs változás, egy másik tagra költözik és ott indul újra Windows Server 2012 és R2 lehet a VM

26 Optimális VM elhelyezés Upon Hyper-V Anti-Affinity failover, cluster VMs keeps with restart related VMs in on priority VMs each apart node order Az affinitiás szabályai szerint a VMek kétféle jellemzővel bírhatnak: Preferált tulajdonos Lehetséges tulajdonos Az AntiAffinityClassNames tulajdonság alapján viszont az adott virtuális gépek nem futhatnak azonos fürttagon Konfigurálható: Powershell vagy SCVMM

27 A virtuális gépek automatikusan átkerülnek leálláskor egy másik fürttagra, azaz a legjobb fürttagra Legjobb = a legtöbb szabad RAM-ot birtokló A VM priorizáció figyelembevételével Konfigurálható > (Get-Cluster).DrainOnShutdown Az alapértelmezett érték az 1-es, tehát a drain mód Ajánlás Továbbra is célszerű a fürttagok megjelölése újraindítás/leállítás előtt

28 Detektálás az adott virtuális gép szintjén Health Monitoring A virtuális gépekben hálózatonként konfigurálható Recovery Hálózatvesztés esetén > live migration De először ellenőrzi a célhelyen az adott hálózatot Live migration

29 ServerA ServerB Server1 ServerC Replica broker Server2 Server3 Hibatűrő fürt 1 Hibatűrő fürt 2

30

31

32 Budapest Sysadmin Meetup Failover Cluster 1x1 Gál Tamás Cloud Infrastructure TSP Microsoft Magyarország