Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Cluster Extension for XP and EVA.

Similar presentations


Presentation on theme: "© 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Cluster Extension for XP and EVA."— Presentation transcript:

1 © 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Cluster Extension for XP and EVA 2007 Dankwart Medger – Trident Consulting S.L.

2 CLX/Cluster overview

3 Till Stimberg, SWD EMEA 26-Oct-063 Protection level (Distance) Wide variety of interconnect options Regional or wide-area protection Support local to global Disaster Tolerant solutions Data Currency (Recovery Point Object) Synchronous or asynchronous options available Data consistency is always assured Performance requirements Asynchronous Continuous Access provides minimum latency across extended distances Performance depends on bandwidth to remote data center Failover time (Recovery Time Object) Manual failover to secondary site Fully automated failover with geographically dispersed clusters on HP-UX, Solaris, AIX, Linux, Windows Disaster Tolerant Design Considerations

4 Till Stimberg, SWD EMEA 26-Oct-064 App A App B App A Cluster Server Clustering Purpose Protect against failures at the host level Server failure Some infrastructure failures Automated failover incl. necessary arbitration Local distances Limits Does not protect against Site disaster Storage failure Core infrastructure failure A major disaster can mean full restore from tape tapes should therefore be stored off-site

5 Till Stimberg, SWD EMEA 26-Oct-065 Storage Replication Purpose Copy of your data in a remote site In case of a major disaster on the primary site no tape restore necessary data still available on remote site operation can be resumed on remote site Long distances through FC Extension technologies and async replication technologies Limits Human intervention to resume operation on remote site Standby system difficult to maintain App A App B App A Array based replication WAN Cluster

6 Till Stimberg, SWD EMEA 26-Oct-066 The solution Cluster Extension/Metrocluster combines with to build a failover cluster spanning two data centers. Benefits Fully automated application failover even in case of site or storage failure No manual intervention No server reboots, no presentation changes, no SAN changes Intelligent failover decision based on status checking and user settings No simple failover script Integrated into standard OS cluster solution No change to how you manage your cluster today Host IO limited to local array Reducing intersite traffic, enabling long distance, low bandwidth setups the remote replication capabilities of the EVA and XP the automated failover capabilities of a standard server cluster

7 Till Stimberg, SWD EMEA 26-Oct-067 Cluster Extension – the goal App A App B Continuous Access EVA/XP App A App B Automated by CLX Arbitrator Node* *type of arbitrator depends on cluster App A Slide is animated

8 Till Stimberg, SWD EMEA 26-Oct-068 HP – XPHP – EVA HP-UX MC/SG Metrocluster sync & async, journaling CA Metrocluster sync CA (future: async) Windows MSCS Cluster Extension sync & async, journaling CA Cluster Extension sync CA (future: async) Solaris VCS Cluster Extension sync & async, journaling CAfuture AIX HACMP Cluster Extension sync & async, journaling CA future Linux MC/SG Cluster Extension sync & async, journaling CA Cluster Extension sync CA (future: async) VmWarefuture Automated failover solutions availability for all major platforms

9 Till Stimberg, SWD EMEA 26-Oct-06 Cluster extension for Windows Cluster Extension XPCluster Extension EVA Array supportXP48/128/512/1024/10000/12000EVA 3000/4000/5000/6000/8000 OS supportWindows 2000 Advanced Server and Data Center Edition Windows 2003 Server Standard/Enterprise (32/64 bit) and Datacenter Edition (64bit) Windows 2003 Server Standard/Enterprise x64 Edition Windows 2003 Server Standard/Enterprise (32/64 bit) and Datacenter Edition (64bit) Windows 2003 Server Standard/Enterprise x64 Edition Cluster SupportMS Cluster (MS certified as geographically dispersed cluster solution) Replication technology Continuous Access XP (synchronous, asynchronous, journaling) Continuous Access EVA (synchronous, asynchronous planned) Distance, inter- site technology No CLX specific limits; must stay within cluster and replication limitations 500 km with not more than 20 ms roundtrip latency ArbitrationCLX Quorum Filter Service (Windows 2000/2003) or MS Majority Node Set (Windows 2003) (including file share witness) MS Majority Node Set (including file share witness) LicensingLicensed per cluster node

10 Till Stimberg, SWD EMEA 26-Oct-063-Jun-1410HP confidential Cluster integration example: CLX for Windows File Share Network Name IP Address Physical Disk CLX All Physical Disk resources of one Resource Group depend on a CLX resource Very smooth integration Example taken from CLX EVA

11 Till Stimberg, SWD EMEA 26-Oct-06 CLX EVA Resource Parameters Cluster node – data center location Failover behavior setting SMI-S communication settings SMA – data center location DR Group for which the CLX resource is responsible for All dependent disk resources (Vdisks) must belong to that DR Group This field must contain the full DR Group name including the \Data Replication\ folder and is case sensitive Data concurrence settings EVA – data center location Pre/Post Exec Scripts

12 Till Stimberg, SWD EMEA 26-Oct-06 CLX XP Resource Parameters Cluster node – data center location Failover behavior setting CA resync setting Pre/Post Exec Scripts Fence Level settings XP arrays and Raidmanager Library Instances Device Group managed by this CLX resource All dependent disk resources must belong to that Device Group

13 Cluster Arbitration and CLX for Windows

14 Till Stimberg, SWD EMEA 26-Oct-0614 Local Microsoft Cluster – Shared Quorum disk Quorum App A App B App A App B Quorum Traditional MSCS uses Shared Quorum disk keep the quorum log keep a copy of the cluster configuration propagate registry checkpoints arbitration, if LAN- connectivity is lost Shared application disks store the application data

15 Till Stimberg, SWD EMEA 26-Oct-0615 Challenges with dispersed MSCS Managing data disks Check data disk pairs on failover Allow data disk failover only if current and consistent Managing quorum disk (for a traditional shared quorum cluster) Mirror quorum disk to remote disk array Implement quorum disk pair and keep challenge/defense protocol working as if it is a single shared resource Filter SCSI Reserve/Release/Reset and any necessary IO commands without performance impacts Prevent split-brain phenomena

16 Till Stimberg, SWD EMEA 26-Oct-0616 Majority Node Set Quorum (1) New Quorum mechanism introduced with Windows 2003 Shared application disks store the application data Quorum data on local disk used to keep a copy of the cluster configuration synchronized by the Cluster Service No common quorum log and no common cluster configuration available => changes to the cluster configuration are only allowed, when a majority of nodes is online and can communicate. App A App B App A App B Quorum

17 Till Stimberg, SWD EMEA 26-Oct-0617 Majority Node Set Quorum (2) MNS arbitration rule: In case of a failure, the cluster will survive, if a majority of nodes is still available In case of a split site situation, the site with the majority will survive Only nodes which belong to the majority are allowed to keep up the cluster service and could run applications. All others will shut down the cluster service. App A App B Quorum App A App B Quorum The majority is defined as: ( /2) + 1 Slide is animated

18 Till Stimberg, SWD EMEA 26-Oct-0618 Majority Node Set Quorum (3) App A App B App A Quorum App B Slide is animated

19 Till Stimberg, SWD EMEA 26-Oct-0619 Majority Node Set Quorum (3) App A App B Quorum # cluster nodes# node failures App A App B Quorum App A Slide is animated

20 Till Stimberg, SWD EMEA 26-Oct-0620 Majority Node Set Quorum (4) - File Share Witness What is it? A patch for Windows 2003 SP1 clusters provided by Microsoft (KB921181)KB What does it do? Allows the use of a simple file share to provide a vote for an MNS quorum-based 2-node cluster In addition to introducing the file share witness concept, this patch also introduces a configurable cluster heartbeat What are the benefits? The arbitrator node is no longer a full cluster member. A simple file share can be used to provide this vote. No single subnet requirement for network connection to the arbitrator. One arbitrator can serve multiple clusters. However, you have to set up a separated share for each cluster. The abitrator exposing the share can be a standalone server a different OS architecture (e.g. a 32-bit Windows server providing a vote for a IA64 cluster)

21 Till Stimberg, SWD EMEA 26-Oct-0621 Majority Node Set Quorum (5) - File Share Witness # cluster nodes# node failures App A App B App A App B \\arbitrator\share Get vote 1 with MNS fileshare witness App A Slide is animated

22 Till Stimberg, SWD EMEA 26-Oct-0622 Majority Node Set Quorum (6) - File Share Witness \\arbitrator\share1 MNS Private Property: MNSFileShare = \\arbitrator\share1 MNS Private Property: MNSFileShare = \\arbitrator\share2 \\arbitrator\share2 Cluster 2 Cluster1

23 Till Stimberg, SWD EMEA 26-Oct-0623 File Share Witness - Installation & Configuration Installation Download the update from Install it on each cluster node -> a reboot is required ! This will add a new private property to the MNS resource Configuration Set the MNSFileShare property to the share you created on the arbitrator Command: cluster resource /priv MNSFileShare=\\servername\sharename Important: The account under which the cluster service is running must have read and write permission to the share After setting the property, the MNS resource has to moved to activate the new setting. C:\>cluster. resource MNS /priv Listing private properties for 'MNS': T Resource Name Value S MNS MNSFileShare D MNS MNSFileShareCheckInterval 240 (0xf0) D MNS MNSFileShareDelay 4 (0x4)

24 Till Stimberg, SWD EMEA 26-Oct-0624 File Share Witness - Prerequisits Cluster Windows 2003 SP1 & R2 (x86, x64, IA64*, EE and DC) 2-node MNS quorum-based cluster Property will be ignored for >2 node clusters Arbitrator OS requirements Windows 2003 SP1 or later MS did not test earlier/other OS versions even though they should work Server OS is recommended for availability and security File Share requirements One file share for each cluster for which the arbitrator provides a vote 5 MB per share are sufficient The external share does not store the full state of the cluster configuration. Instead, the external share contains only data sufficient to help prevent split-brain syndrome and to help detect a partition-in-time Cluster Service account requires read/write permission For highest availability, you might want to create a clustered file share/file server * There is no Windows Server 2003 R2 release for IA64 (Itanium)

25 Till Stimberg, SWD EMEA 26-Oct-0625 File Share Witness - additional parameters MNSFileShareCheckInterval This is the interval when the cluster service checks if it can write to the file share. If this verification fails, a warning event is logged in the system event log min: 4 sec default: 240 sec max: sec MNSFileShareDelay Delay in seconds that the cluster node (which does not currently own the MNS quorum resource) will wait until it tries to get the vote from the witness. This allows the current owner of the MNS quorum resource be preferred when trying to win the vote. min: 0 sec default: 4 sec max: 60 sec C:\>cluster. resource MNS /priv Listing private properties for 'MNS': T Resource Name Value S MNS MNSFileShare \\arbitrator\share D MNS MNSFileShareCheckInterval 240 (0xf0) D MNS MNSFileShareDelay 4 (0x4)

26 Till Stimberg, SWD EMEA 26-Oct-0626 File Share Witness/Arbitrator - What does it mean for CLX? Remember: File Share Witness only works with 2-node clusters Abitrator Node requirementCLX with traditional MNSCLX with MNS using file share witness Cluster MembershipArbitrator is a full additional cluster memberand has full cluster configuration information. Arbitrator is external to the cluster and has only minimal cluster configuration information. Operating SystemSame Windows version as on other cluster nodes, e.g. if IA64 cluster, abitrator has to be IA64 server, as well. Can be different Windows versions, e.g. 32-bit fileshare witness (arbitrator) can serve 64-bit cluster. HardwareDetermined by the OS. Arbitrator could be a smaller, less powerfull machine than the main nodes Determined by the OS. Fileshare server could be a smaller, less powerfull machine than the main nodes. Due to the less strict OS requirements, the hardware selection is also more flexible. Multiple ClustersOne arbitrator node per cluster.One arbitrator can serve multiple clusters. Location3rd site Network requirementsSingle subnet. Should NOT be dependent on a network route (physically) through one DC in order to reach the other DC. Can be a routed network (different subnets). Should NOT be dependent on a network route (physically) through one DC in order to reach the other DC.

27 Till Stimberg, SWD EMEA 26-Oct-0627 CLX XP Quorum Filter Service (QFS) Component of CLX XP for Windows Required for Windows 2000 Optional for Windows 2003 can also use MNS QFS provides some benefits over MNS Functionality Allowing use of Microsoft share quorum cluster across two Data Center and XPs Implements filter drivers that intercept quorum arbitration commands and uses additional CA pairs to make cross site decision external arbitrator for automated failover even in case of full site failure or split

28 Till Stimberg, SWD EMEA 26-Oct-0628 CLX XP Quorum Filter Service Components clusdisk diskRM APIclxqsvc clxspflt scsi/stor port User Components IO Path Kernel Components Kernel to user mode communication Windows Service Service Dependencies Quorum disk pair control Create Recover Swap RESET TUR clxqflt RESERVE RELEASE RESET Quorum CTRL1 CTRL2 CTRL3

29 Till Stimberg, SWD EMEA 26-Oct-063-Jun-1429HP confidential CLX XP on Windows – Server failure App A App B Quorum reserved by left node App B Quorum App A Quorum CTRL1 CTRL2 CTRL3 reserved by right node Quorum CTRL1 CTRL2 CTRL3 reserved by right node Slide is animated

30 Till Stimberg, SWD EMEA 26-Oct-063-Jun-1430HP confidential CLX XP on Windows – LAN split App A App B App A Quorum App B Quorum CTRL1 CTRL2 CTRL3 Quorum CTRL1 CTRL2 CTRL3 reserved by left node App B Slide is animated

31 Till Stimberg, SWD EMEA 26-Oct-063-Jun-1431HP confidential CLX XP on Windows – site failure App B Quorum CTRL1 CTRL2 CTRL3 reserved by left node App A Quorum CTRL1 CTRL2 CTRL3 reserved by left node App B cdm External Arbitrator App A reserved by right node Quorum App A Slide is animated

32 Till Stimberg, SWD EMEA 26-Oct-0632 Majority Node SetQuorum Filter Service Pros Solution owned by Microsoft Works with both CLX EVA and XP MS prefered solution for geographically dispersed clusters Most likely the CLX solution going forward Pros Shared quorum, hence can survive node failovers down to a single node Allows asymmetric cluster setups Windows 2000 and Windows 2003 Cons Requires symmetric node setup For >2 nodes one additional node per cluster is required Will only survive with a majority of nodes Forced majority requires another downtime to reform original cluster Windows 2003 only Cons More intrusive More difficult to maintain across Service Packs and other updates Full site failure or split will first result in cluster service shutdown before external arbitrator kicks in (if quorum disk was in the remote data center) Majority Node Set vs CLX XP Quorum Filter Service Recommended quorum mechanism for new installs

33 Manual vs Automated failover – failover times

34 Till Stimberg, SWD EMEA 26-Oct-0634 Automated failover Question: How long does a CLX failover take? Answer: Depends !!! CLX failover is first of all still a cluster failover There are components influencing the total application failover time, which are out of control of CLX Failure recognition, cluster arbitration, application startup The CLX component of the total failover time also depends on many factors.

35 Till Stimberg, SWD EMEA 26-Oct-0635 Factors affecting the automated failover times in a CLX for Windows cluster Recognize failure Cluster arbitration Start application on other node CLX failover PhaseFactors influencing time Time to recognize failure Resource failures resources timeouts (e.g. disk timeouts) potentially resources restarts until the cluster moves the group to another node Node(s), network or whole DC failure Cluster heartbeat timeouts to decide that communication to node(s) is lost Time for cluster arbitration Only happens in case of a node or network failure Time depends on network latency, heartbeat settings and cluster size Time for CLX to failover replication Type of components that fails Node failure Storage failure Management Server failure Intersite communication Time to start application on surviving node Application type and size Required recovery steps (e.g. log replay) (5 sec – 5 min)

36 Till Stimberg, SWD EMEA 26-Oct-0636 CLX failover times (applies to Metrocluster, as well) CLX XP Up to 5 Raid Manager XP commands (For typical configs only 3) Default Raid Manager XP command timeout is 30 sec Max. CLX failover time: 5 x 30 sec x (number of remote hosts + 1) Quorum Filter Service controls quorum disk pair failover in < 3 seconds If arbitrator assistance is needed cluster restart might take up to 6 minutes CLX EVA Theoretically Up to 12 SMI-S calls (7 if the CA link is up) Default SMI-S timeout is 180 sec Realistically, 12 (7) x 180 sec will never happen: If CLX times out, it will try the next management server, where it either succeeds or also fails, which will result in a CLX resource failure Realistically, you can expect up to 5 minutes In case of a simple node failure, application move with CLX failover will take just a few (5-20) seconds longer than without remote replication.

37 Till Stimberg, SWD EMEA 26-Oct-0637 Manual vs. automated failover times Typical example of a manual failover is a Stretched cluster Cluster stretched across two sites, but all nodes accessing the same array which replicates the data to a remote partner. Even in case of a node failure the primary storage array will be used (across a remote link if node is in remote data center) A storage or site failure will bring down the cluster requiring manual intervention to start cluster from remote array. Steps involved in case of a storage failure Notification of operator (15 min*) Evaluation of the situation and necessary recovery steps (30 min*) Shutdown surviving cluster node (5 min*) Replication failover (2 min*) Start up surviving cluster nodes (10 min*) The effort mulitplies with the number of application/clusters/arrays being affected *times are just examples and will vary depending on the situation and setup. A full site disaster for instance might involve much more troubleshooting and evalution time.

38 Till Stimberg, SWD EMEA 26-Oct-0638 Manual vs. automated failover times - single cluster Notification of operator Evaluation of the situation and necessary recovery steps Shutdown Start Servers time (min ) Failover manual automated (CLX) Recognize failure Cluster arbitrator CLX failover Application startup Total = 62 min* Total = 10 min* *times are just examples and will vary depending on the situation and setup

39 Till Stimberg, SWD EMEA 26-Oct-0639 Manual vs. automated failover times - multiple clusters time (min ) manual automated (CLX) Total = 96 min* Total = 10 min* cluster 1 cluster 2 cluster 3 cluster 1 cluster 2 cluster 3 *times are just examples and will vary depending on the situation and setup

40 Till Stimberg, SWD EMEA 26-Oct-0640 Other advantage CLX helps to avoid human mistakes Manual failover operations introduce the risk of making mistakes, failing over the wrong DR Group, etc. CLX simplifies planned failover for maintenance Similar to disaster failover, just faster Manual failover still requires same steps besides the notification and evaluation Failback is as simple as a failover Once the primary site is restored, its just another cluster failover Manual failback is as complex and intrusive as maintenance failover

41 Till Stimberg, SWD EMEA 26-Oct-0641 External information Cluster Extension EVA Cluster Extension XP Link to Metrocluster EVA Link to Metrocluster XP Disaster-Tolerant Solutions Library (Solutions for Serviceguard) Continental Cluster CA EVA CA XP x.htmlhttp://www.hp.com/products1/storage/products/disk_arrays/xpstoragesw/continuousaccess/inde x.html CLX EVA migration whitepaper and Exchange replication whitepaper (incl. CLX)

42 Till Stimberg, SWD EMEA 26-Oct-0642 Internal information CLX EVA for Windows Sharepoint (maintained by Till Stimberg) CLX XP for Windows Sharepoint (maintained by Anton Vogel) CLX/Metrocluster streams on SPOCK

43


Download ppt "© 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Cluster Extension for XP and EVA."

Similar presentations


Ads by Google