Pepug 54 Exchange managed availability
•Als PPTX, PDF herunterladen•
0 gefällt mir•485 views
Exchange 2013 Managed Availability - explanation with examples and conection to SCOM
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Pepug 54 Exchange managed availability
Ähnlich wie Pepug 54 Exchange managed availability (18)
Pepug 54 Exchange managed availability
- 3. User Architektura Exchange 2013 Przy połączeniu do skrzynki, protokół wykorzystany do połączenia jest zawsze udostępniany przez serwer, na którym jest aktywna kopia bazy danych Obsługa serwisowa Exchange Online zmieniła mechanizmy monitorowania Rozbudowana automatyzacja Monitorowanie Layer 4LB CAS DAG1 MBX-A MBX-A MBX-B MBX-B
- 5. Doświadczenia zebrane przez grupę wsparcia Office365 Monitorowanie oparte na doświadczeniach użytkowników Optymalizacja Exchange pod kątem odtwarzania funkcjonalności
- 7. Jeżeli nie możesz czegoś zmierzyć, nie możesz tym zarządzać Customer Touch Points Dostępność Dostępność Czy usługa jest dostępna? Opóźnienie Jakie jest moje doświadczenie? Błędy Czy jestem w stanie uzyskać to co chcę? Opóźnienie Błędy
- 8. “stuff breaks and the Experience does not” LB CAS-1 DAG MBX-1 OWA OWA DB1 DB1 DB2 DB1 DB1 DB2 DB1 DB2 MBX-2 CAS-2 OWA MBX-3 OWA —OWA send —OWA failure —OWA fast recovery —OWA verified as healthy —OWA send —OWA failure —OWA fast recovery —Failover server’s databases —OWA verified as healthy —Server becomes “good” failover target (again)
- 9. Managed Availability Exchange 2013 Server “take human driven action” Managed Availability “state of the world” “restore service or prevent failure”
- 10. 20s 5min PROACTIVE 20min REACTIVE System Level Checks Mailbox Self Test (e.g. OWA MST) [detection 5m] Protocol Self Test (e.g. OWA PST) [detection 20 secs] Proxy Self Test (e.g. OWA PrST) [detection 20 secs] End User Experience Level Checks Customer Touch Point – CTP (e.g. OWA CTP) [detection 20m]
- 12. “take human driven action” “state of the world”
- 13. “take human driven action” “restore service or prevent failure”
- 14. Próbkowanie Probe Definition Probe Results (Samples) Probe Wykrywanie Monitor Definition Monitor Monitor Results (Alerts) Odtwarzanie Responder Definition Responder Responder Results (Responses) Monitor States Healthy Notification Item 00:00:00 Przykład potoku sekwencyjnego respondera HA T1 Restart Responder Reset AppPool Responder 00:00:10 T2 Failover responder Bugcheck responder Offline Responder 00:00:30 T3 Escalate Responder Named Times
- 17. Recovery Enable Action d Per Server Per Group Minutes Between Actions Max Allowed Per Hour Max Allowed Per Day Minutes Between Actions Max Allowed Per Day ForceReboot True 720 N/A 1 600 4 SystemFailover True 60 N/A 1 60 4 RestartService True 60 N/A 1 60 4 ResetIISPool True 60 N/A 1 60 4 DatabaseFailover True 120 N/A 1 120 4 ComponentOffline True 60 N/A 1 60 4 ComponentOnline True 5 12 288 5 Large MoveClusterGroup True 240 N/A 1 480 3 ResumeCatalog True 5 4 8 5 12 WatsonDump True 480 N/A 1 720 4
- 21. CTP Health Set Proxy Health Set OWA.Proxy OWA Protocol Health Set OWA.Protocol
- 22. Get-ServerHealth pokazuje szczegółowe informacje o „stanie zdrowia” serwera lub grupy serwerów Get-HealthReport operuje na tych samych danych pokazując zwięzły raport Jak sprawdzić, które próbniki, monitory i respondery są powiązane z danym Healt Setem? Get-MonitoringItemIdentity –Identity <HealthSet> -Server <ServerName> | ft identity,itemtype,healthsetname,name -auto
- 23. Bardziej szczegółowe wyniki – tylko „niezdrowe” komponenty get-healthreport -server srv-ex1 | where {$_.alertvalue -ne “healthy”} | ft – auto
- 24. Informacja o restartach realizowanych przez respondery: $RecoveryActionResultsEvents = Get-WinEvent –ComputerName srv-ex1 -LogName Microsoft-Exchange-ManagedAvailability/RecoveryActionResults $RecoveryActionResultsXML = ($RecoveryActionResultsEvents | Foreach-object Process {[XML]$_.toXml()}).event.userData.eventXml $RecoveryActionResultsXML > c:Scriptsrecoveryresults.txt
- 25. View Overrides Get-ServerMonitoringOverride –Server <Server> Get-GlobalMonitoringOverride Create Override Add-ServerMonitoringOverride <HealthSet><Name> -Server <Server> -ItemType <Monitor,Probe,Responder> [-Duration <Time> -ApplyVersion <Version>] -PropertyName <Property> -PropertyValue <Value> Add-GlobalMonitoringOverride <HealthSet><Name> -ItemType <Monitor,Probe,Responder> [-Duration <Time> -ApplyVersion <Version>] -PropertyName <Property> -PropertyValue <Value> Remove Override Remove-ServerMonitoringOverride Remove-GlobalMonitoringOverride
- 26. Alert wyeksponowany w konsoli SCOM, niekoniecznie wskazuje sumę wszystkich problemów w danym momencie Active Alerts Organization Health Server Health
- 27. Stan Health Groupy jest wyliczany na podstawie stanu monitorów w danej grupie Health Group może mieć jeden z sześciu stanów: Healthy, Degraded, Unhealthy, Repairing, Disabled lub Unavailable