1 / 82

2009 하반기 SMA 세미나 HACMP Best Practices

2009 하반기 SMA 세미나 HACMP Best Practices. 2009. 10. 15. 백진훈 (jhb@kr.ibm.com) MTS, GTS, IBM Korea. 목차. 1. HACMP 개요 2. 요소별 고려사항 3. 실 고객 구성 사례 4. HACMP with PowerVM 5. Do’s and Don’ts 6. 첨부. Contents. 1. PowerHA Message. HACMP is now PowerHA for AIX

kenda
Download Presentation

2009 하반기 SMA 세미나 HACMP Best Practices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2009 하반기 SMA 세미나HACMP Best Practices 2009. 10. 15. 백진훈 (jhb@kr.ibm.com) MTS, GTS, IBM Korea

  2. 목차 1. HACMP 개요 2. 요소별 고려사항 3. 실 고객 구성 사례 4. HACMP with PowerVM 5. Do’s and Don’ts 6. 첨부 Contents 1

  3. PowerHA Message • HACMP is now PowerHA for AIX Renamed as part of Power software initiative Publications and product (binaries) continue to use HACMP PowerHA: Faster, Simpler, Goes the Distance!

  4. 개요 및 문제점 HACMP : • 1991년에 출시, 최신 5.5까지 20번째 release • 전세계적으로 production 환경에서 60,000 이상의 Reference • AIX 기반의 강력하고 안정적인 고 가용성 Product • 다양한 형태의 유연한 구성 지원 • 구성단계에서 검증 절차도 통과되어 작동되고, 운영 중이기는 하지만 실제 고 가용성을 제공해야 한다는 측면에서 볼 때는 최적의 구성이 아닌 경우가 있음 • 높은 수준의 가용성을 확보하기 위해서 고려되어야 할 점들은 무엇인가?

  5. Why do good clusters turn bad? HACMP가 제대로 작동하지 않는 일반적인 이유 : • 잘못된 cluster design과 철저하지 못한 planning - design, planning, test • 기본 TCP/IP and LVM 구성 문제 • HACMP cluster topology and resource 구성 문제 • Cluster를 운영하는데 있어 변경관리 규율(통제) 부재 • Cluster 관리자에 대한 교육 부족 • Performance/capacity 문제

  6. Designing High Availability • “…A fundamental design goal of (successful) cluster design is the elimination of single points of failure (SPOFs) through appropriate design, planning, selection of hardware, configuration of software, and carefully controlled change management discipline.…”

  7. Fault resilience vs. Fault tolerance High Availability does not mean no interruption to the application thus we say, fault resilient instead of tolerant.

  8. Eliminating single points of failure • “…A fundamental design goal of (successful) cluster design is the elimination of single points of failure (SPOFs).…”

  9. 목차 1. HACMP 개요 2.요소별 고려사항 3. 실 고객 구성 사례 4. HACMP with PowerVM 5. Do’s and Don’ts 6. 첨부 Contents 2

  10. HACMP Cluster Configuration – Step by Step Cluster Name: Cluster 1 • Topology Components: • Cluster name • Node Names • IP Network • Interfaces • Serial Network • Types of Resources • Service IP • Volume Group/s • Application Server • Resource Components: • Resource Group/s • Policies • - startup • - fallover • - fallback • Dependencies • Parent / Child • Location Network: net_ether0 NODE A NODE B RG1 (NodeA, NodeB) RG2 (NodeB) Service IP Volume Group Development App Network: rs232_net Service IP Volume Group Production App Network: diskhb_net Storage Subsystem

  11. HACMP Location Dependencies Cluster Name: Cluster 1 Network: net_ether0 • Location Dependencies: • RGs can coexist on same node • RGs can coexist on different nodes • Can also set Priorities: • High • Intermediate • Low • Diagram Assumptions: • RG1 – High Priority • RG2 – Low Priority • On Fallover: • RG2 Offline • RG1 will move to Node B NODE A NODE B RG1 (NodeA, NodeB) RG2 (NodeB) Service IP Volume Group Development App Network: rs232_net Service IP Volume Group Production App Network: diskhb_net Storage Subsystem

  12. HACMP Fallover Scenarios Mutual Fallover Cluster Name: Cluster 1 Network: net_ether0 • Environment: • - Each Machine is running its own • Production application • - Node A fails to Node B • - Node B fails to Node A • Fallover Behavior: • On fallover the target machine will • need enough CPU & memory • resources in order to handle the • load of both applications NODE A NODE B RG1 (NodeA, NodeB) Service IP Volume Group Application 1 RG1 (NodeA, NodeB) RG2 (NodeB, NodeA) Service IP Volume Group Application 2 ONLINE Network: rs232_net Service IP Volume Group Application 1 RG2 (NodeB, NodeA) Service IP Volume Group Application 2 ONLINE Network: diskhb_net Storage Subsystem

  13. Resource Group Tips RG Decisions beyond: Startup Fallover & Fallback behavior NODE B NODE A Further Options • 1 RG vs. Multiple RGs • Selective Fallover behavior (VG / IP) • RG Processing • Parallel vs. Sequential • Delayed Fallback Timer • RG Dependencies • Parent / Child • Location Dependencies RG2 (NodeB, NodeA) RG1 (NodeA, NodeB) Service IP VG2 APP Server 2 Service IP VG1 APP Server 1 RG4 (NodeB, NodeA) RG3 (NodeA, NodeB) Service IP VG4 APP Server 4 Service IP VG3 APP Server 3 Best Practice: Always try to keep it simple, but stay current with new features and take advantage of existing functionality to avoid added manual customization.

  14. Cluster Components Nodes • up to 32 nodes, active와 standby nodes의 조합 • 모든 node가 running인 구성이 가능 (mutual takeover) • 신뢰할 만한 cluster들은 최소한 한 개의 standby node가 있음 • 공동의 power supply를 가지면 안됨. Ex) 단일 rack에 위치하는 power supply • 단일 frame내에 lpar로 cluster node를 생성해서는 안됨. • 여분의 network, disk adapter들을 설치할 수 있는 충분한 I/O slot이 있어야 함 • 즉, Single node에 필요한 수량의 두 배수 만큼의 slot • 모든 cluster resource는 backup이 있어야 함, 각 node의 rootvg는 mirror되거나 RAID device에 놓여야 함

  15. Cluster Components(Cont.) Nodes • Production application이 peak로 수행될 때에도 HACMP가 정상적으로 작동되도록 충분한 CPU cycles과 I/O bandwidth가 확보되어야 함 • Takeover를 고려할 때 resource 사용률이 40% 이하를 유지해야 함 • 단일 standby node가 여러 active node를 backup하면, 모든 가능한 workload를 수행할 만큼의 충분한 용량이 확보 되어야 함 • Dlpar를 지원하는 H/W에서, application이 기동되기 전에 node를 takeover하기 위해서는 HACMP가 processor와 memory를 할당 받아 구성할 수 있어야 함. 모든 resource(CPU, memory)는 사용 가능하거나, CoD를 통해서 획득 가능해야 함

  16. HACMP HACMP DLPAR/CoD configuration • Primary node에서 HACMP가 장애를 감지 • Running in a partition on another server, HACMP grows the backup partition, activates the required inactive processors and restarts application DLPAR/CoD Server (running applications on active processors) Production Database Server Active Processors Inactive Processors Web Server Order Entry Database Server Shared Disk HACMP HACMP

  17. Configuration Requirements • HMC IP와 관리대상 시스템의 이름은 각 DLPAR에 구성되어야만 함 • 모든 DLPAR node들은 HMC와 SSH를 이용한 통신이 가능해야만 함 - clverify checks the SSH connectivity • Cod를 사용할 경우 key값은 HMC를 통해 수작업으로 활성화 되어야 함 • HACMP가 구성할 수 있는 최대 resource는 DLPAR profile 상의 최대 값과 같거나 그 이하임

  18. Shared Disk HACMP with micro-partition • Takeover로 인한 업무 증가로 CPU자원이 더 필요함 • hypervisor에서 각 파티션의 CPU사용률을 모니터링하고 CPU자원이 필요한 파티션에 더 많은 CPU자원을 할당함 100 100 WAS 서버 개발 서버 0 0 CPU 사용률 CPU 사용률 Micro-Partition 환경 하에서 하이퍼바이저가 자동으로 CPU 자원을 동적으로 이동하여 부하를 조절함. 100 100 Test 서버 1 Test 서버 2 Production 서버1에 장애 발생 & fallover 0 0 CPU 사용률 CPU 사용률 100 100 Production 서버1 (active) Production 서버2 0 0 CPU 사용률 CPU 사용률

  19. Infrastructure Considerations • Power Redundancy • I/O Drawers • SCSI Backplane • SAN HBAs • Virtualized Environments • Application Fallover Protection Real Customer Scenarios: Ie 1. SCSI adapters for rootvg on same BUS Ie 2. Two nodes sharing I/O drawer I/O drawer 1 6 I/O drawer 2 7 I/O drawer 3 8 I/O drawer 4 9 5 I/O drawer 10 Moral of the Story: * High Availability goes beyond just installing the cluster software

  20. 내장 SCSI 디스크 상의 Single Point of Failure # lsdev -Ccdisk hdisk0 Available 0A-08-00-8,0 16 Bit LVD SCSI Disk Drive hdisk1 Available 0A-08-00-9,0 16 Bit LVD SCSI Disk Drive hdisk2 Available 0A-08-00-10,0 16 Bit LVD SCSI Disk Drive # # lsdev -Cc adapter …………….. scsi0 Available 0A-08 Wide/Ultra-3 SCSI I/O Controller …………….. Single Point of Failure

  21. 0 r o o t v g 2 1 r o o t v g r o o t v g Single Point of Failure 예시(IO Drawer) Internal Disk Drive ( 전면 ) PCI Adapter ( 후면 ) e n t 16 e n t 12 f c s 2 f c s 8 f c s 15 f c s 5 e n t 48 f c s 1 Emp T y Emp T y e n t 4 e n t 8 f c s 3 f c s 4 f c s 0 S A 0 f c s 6 f c s 7 Emp T y e n t 20 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 e n t 40 e n t 36 f c s 11 f c s 14 e n t 28 f c s 10 Emp T y Emp T y e n t 24 e n t 32 f c s 12 f c s 13 f c s 9 S A S 0 f c s 16 f c s 17 f c s 18 f c s 19 Emp T y e n t 44 L8 L9 L10 L11 L8 L9 L10 L11 L8 L9 L10 L11 L8 L9 L10 L11 T6 T5 T6 T5 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Planar 2 Planar 2 Planar 1 Planar 1

  22. p595 Benefit of Boot from SAN • 구성의 유연성 • - Power 시스템의 Internal adapter & • - Bay 등의 제한에 따른 LPAR 구성 한계를 극복 • High performance - 내장 Disk 대비 월등한 외장 스토리지의 I/O 성능 활용가능 - 외장 스토리지의 Disk cache 활용 • High reliability - DDM 장애 등에 무관하게 시스템 영속성 보장 - 외장 스토리지의 높은 가용성 활용 - 내부 복제, 원격복제 솔루션 등 활용가능 • 용량 효율성 - 외장 스토리지에 복수개의 OS, backup image 등을 위치시킬 수 있음 - 기존의 DDM size 단위로 rootvg 할당대비 유연한 할당 가능 (ex, 20GB, 40GB) • 손쉬운 AIX 백업 가능 – Flashcopy 가 “mksysb” 를 대체 - Point-In-Time OS backup 을 여러 벌 확보 가능 - OS 백업(Flashcopy target본)을 portable 하게 다른 시스템에서 바로 사용가능 16 core 60GB I/O drawer * 2ea 20GB rootvg X1 30GB datavg X4 30GB appvg X3

  23. Networks • Network은 IP and Non-IP network로 구성됨. IP-Network과 Non-IP Network을 통해서 node간에 통신하며 heartbeat을 주고 받음 • Network 장애인지 Node 장애인지를 구분하기 위해서 non-IP network 구성이 반드시 구성되어야 함 • HACMP는 다음의 세가지 type의 failure만을 다룸: - Network interface card (NIC) failures - Node failures - Network failures VS.

  24. Partitioned Cluster (Split Brain) • IP network 문제로 heartbeat check가 정상적으로 이뤄지지 않아 각 node는 살아있음에도 상대 node가 down 되었다고 판단하여 서로가 takeover를 시도함. • 이로 인해 양 node에서 RG가 동시에 online되는 현상이 발생. • 공유 disk를 사용하는 application이 동시에 기동됨에 따라 data corruption이 발생할 수도 있음 • Proving that Node Isolation caused the problem: – /tmp/clstrmgr.debug file – AIX error log entry GS_DOM_MERGE_ER

  25. Disk Heartbeating vs. RS232 Links • HACMP 5.1에서 소개된 기능 : non-IP heartbeating을 위해 SAN 환경을 활용 • 사용 이유 : - RS232 cables의 거리 제약 - integrated serial ports의 부족 - 일부 model은 integrated port를 heartbeat용으로 사용하는데 제약사항이 있음 - Clusters with more than two nodes may require an async adapter with a RAND • 필요사항 : - 작은 size의 disk 또는 LUN (ex. 1GB) - bos.clvm.enh fileset 설치 - An Enhanced Concurrent Mode VG (RG로 정의될 필요는 없음)

  26. Checking for Fast Failure Detection (FFD) # lssrc –ls topsvcs | grep Fast Fast Failure Detection enabled # odmget –q name=diskhb HACMPnim HACMPnim: name = "diskhb" desc = "Disk Heartbeat Serial protocol" addrtype = 1 path = "/usr/sbin/rsct/bin/hats_diskhb_nim" para = “FFD_ON“ grace = 60 hbrate = 3000000 cycle = 8 gratarp = 0 entry_type = "adapter_type" next_generic_type = "transport" next_generic_name = "" src_routing = 0 Reason to set this option: In the event of a crash this option will allow for the takeover to start up immediately instead of waiting for the Failure Detection Rate timeout to pass. Note: new feature starting with HACMP 5.4 This change will not take effect until the NIM is recycled during a cluster restart

  27. Important network best practices for high availability • IP address, subnetmasks, switch port setting, VLAN 등의 network단에서의 변경에 조심 • - 장애 감지는 node당 최소 두장의 물리적 adapter가 동일한 물리적 network/VLAN 안에서 있을 때 가능함 • 최소 한 개의 non-IP network을 구성 • Network 가용성 확보 차원에서 HACMP에서 Etherchannel을 구성하여 사용하면 유용함 • 구성 시 secondary switch로 연결된 backup adapter를 포함시켜 구성할 것 • HACMP는 etherchannel 구성을 단일 adapter network으로 간주. adapter 장애 시 문제해결 지원을 위해 netmon.cf file을 별도로 구성. Cluster 외부의 다른 interface로 ICMP echo request(ping)를 전송해서 adapter 장애를 판단 • 각 node에 persistent IP를 구성 - 원격 관리, monitoring에 유용함

  28. HACMP Topology Considerations • IPAT via Replacement vs. IPAT via Aliasing * Considerations: - Max number service IPs within HACMP network - Hardware Address Takeover (HWAT) - Speed of Takeover - Firewall Issues IPAT via Replacement Node ANode B en0 – 9.19.10.1 (boot) en0 – 9.19.10.2 (boot) en0 - 9.19.10.28 (service IP) en0 – 9.19.10.2 (boot) en1 – 192.168.11.1 (standby) en1 – 192.168.11.2 (standby) net_ether_0

  29. HACMP Topology Considerations • Contrast between Replacement & Aliasing Considerations: - Max number service IPs within HACMP network - Speed of swap - Hardware Address Takeover (HWAT) - Firewall Issues IPAT via Aliasing Node ANode B en0 – 192.168.10.1 (base1) en0 – 192.168.10.2 (base1) 9.19.10.28 (persistent a) 9.19.10.29 (persistent b) 9.19.10.51 (service IP) en1 – 192.168.11.1 (base2) en1 – 192.168.11.2 (base2) 9.19.10.50 (service IP) net_ether_0

  30. Etherchannel with HACMP primary secondary • Example of an EtherChannel (Backup) Configuration Network Switches Network: net_ether_0 Node A Node B ent0 ent0 ent2 ent2 en2 10.10.100.1 boot boot 10.10.101.1 en2 ent1 ent1 192.168.10.1 persistent a 192.168.10.2 service IP persistent b 192.168.10.4 Verification Messages: For nodes with a single Network Interface Card per logical network configured, it is recommended to include the file '/usr/es/sbin/cluster/netmon.cf' with a "pingable“ IP address as described in the 'HACMP Planning Guide'. WARNING: File 'netmon.cf' is missing or empty on the following nodes:Node A Node B

  31. Netmon.cf • Etherchannel과 같은 단일 adapter의 장애를 HACMP가 정확하게 판단하기가 어려울 수 있음 • RSCT Topology Services가 단일 adapter의 정상 작동 여부를 확증하기 위해 packet을 강제적으로 전송할 수 없기 때문임 • Etherchannel과 같이 single adapter network 구성에서는 netmon.cf file을 생성. - 일반적으로 default G/W IP 주소를 사용 - 다른 node로 부터의 heartbeat packet 수신이 안되면, 미리 설정되었던 G/W 로 ping을 시도 • /usr/sbin/cluster/netmon.cf Ex) 180.146.181.119 steamer chowder 180.146.181.121

  32. Topology environments with a Firewall If multiple IPs on the same subnet are configured on the same interface AIX will utilize the 1st one configured for the outbound traffic. LAN Node X Clients can talk to the cluster nodes, but node initiated traffic from the 9.19.51.X network will look like its coming from the persistent IP not the service IP en0 – 10.10.10.1 boot 9.19.51.1 persistent IP 9.19.51.2 service IP1 en1 – 10.10.11.1 boot Network set to use IPAT via Aliasing Firewall Tip: If you only need to manage one service IP per HACMP network consider using IPAT via Replacement to avoid having multiple IPs on the same interface.

  33. Topology environments with a Firewall Overriding default AIX behavior sometimes requires some creativity LAN Node X Clients still talk to the cluster nodes via both IPs, but node initiated traffic now from the 9.19.51.X network will look like its coming from the service IP en0 – 10.10.10.1 boot 9.19.51.2 service IP 9.19.51.1 persistent IP en1 – 10.10.11.1 boot Network set to use IPAT via Aliasing Firewall Work around 1: Perform an ifconfig down of the persistent alias within the application start script followed by an immediate ifconfig up to make it the second IP on the list

  34. Topology environments with a Firewall IPAT via Replacement will only host one IP on an interface at any given time hence avoiding multiple IPs within the same subnet LAN Node X When HACMP is activated the base address will be replaced by the new service IP address that the clients use to connect to en0 – 9.19.51.1 boot en1 – 10.10.11.1 standby en0 – 9.19.51.2 service IP1 Network set to use IPAT via Replacement Firewall Work Around 2: If you only need to manage one service IP per HACMP network consider using IPAT via Replacement to avoid having multiple IPs on the same interface.

  35. Enhanced Concurrent VG • AIX 5L V5.1 처음 소개됨 • HACMP에서 사용 가능한 모든 Disk에서 구현 가능함 • JFS and JFS2 filesystems 지원 – File systems은 한번에 한 node에만 mount • 기존의 classic concurrent volume groups을 대체 • Enhanced concurrent VGs는 다음의 기능을 사용하기 위해 필요함 : – Heartbeat over disk for a non-IP network – Fast disk takeover

  36. Converting VG to ECM • Stop Cluster • 한 Node씩 아래와 같은 절차를 수행 - varyonvg <VGNAME> - chvg -C <VGNAME> - varyoffvg <VGNAME> • 모든 Node에서 lsattr -El <VGNAME> 을 통해 VG 의 속성이 이상이 없는지 확인 auto_on n N/A True conc_auto_on n N/A True conc_capable y N/A True • Verification and synchronization

  37. Converting VG to ECM(cont.)

  38. Active varyon vs. passive varyon • Active varyon

  39. Active varyon vs. passive varyon(Cont.) • Passive varyon

  40. Adapters • 다중 port adapter를 사용할 경우 한 adapter내에서 빈 port를 이용하여 backup을 구성해서는 안됨. • Built-in Ethernet adapter를 사용할 경우, Node내에 별도의 backup adapter가 있어야 함 • 가능하면 별도의 IO Drawer 또는 서로 다른 backplane, BUS에 adapter를 위치시켜서 이중화 구성을 해야 함

  41. Applications & application Scripts • 자동화 - 관리자에 의한 수작업 없음 • 일부 application들은 uname이나 serial no. 또는 IP address와 같은 특정한 OS 특성과 밀접한 관계를 보이는 경향이 있음 (ex. SAP) • Application이 현재 running 중인지 확인 - RG가 unmanaged 상태일 때, default startup option을 사용하면 HACMP가 application start script를 재 수행함 • Data 상태 확인. 복구가 필요한가? • Correct Coding : - start with declaring a shell (ex. #!/bin/usr/ksh) - exit with RC=0 - application이 정말 중단되었는지 확인하는 절차 포함 - fuser • Smart Assist : DB2, Websphere, Oracle

  42. Application Monitoring 세가지 type의 monitoring 법 • Startup Monitors – run one time • Process Monitors – check specified process instance in the process table • Custom Monitors – run your specified script during reiterating interval Resource monitors 는 문제 발생 시 단순 알림(notify) event를 수행하도록 구성할 수도 있고, 정상인 상대 node로 서비스가 fallover 되도록 구성할 수도 있음 Don’t stop at just the base configuration - with thorough testing these can be great tools to automate recovery and save an admin time.

  43. Application Monitoring(Cont.) • Configure Process Application Monitors ex)

  44. Application Monitoring(Cont.) • Configure Custom Application Monitors ex)

  45. Testing Best Practices • Production으로 이행하기 전에 application scripts와 application monitoring을 철저히 test해야 함 • 모든 방향으로의 fallover를 test 해야 함 • Test Cluster - Lpars within same frame - Virtual resources • 가용한 Tool을 활용 – Cluster Test Tool - Further customization enhancements in HACMP 5.4 • 정기적인 test 계획이 세워져야 함 – ex) node fallover and fallback test - 최소 반기 1회 이상

  46. Maintenance • 통제된 관리 환경 • - 고 가용성을 확보하기 위해 가장 중요한 것 : 엄격한 변경제어, 변경절차 관리, Test • Cluster node에 변경작업을 하기 전에 HACMP snapshot을 받아 놓아야 함 • OLPW(Online Planning Worksheet)을 이용한 HTML 보고서 생성 - http://www-03.ibm.com/systems/power/software/availability/aix/apps/download.html • CSPOC operations • - Cluster Single Point of Control • - No TIPing (Testing In Production) : Production 환경에서는 절대로 test 해서는 안됨 • Production과 동일한 test cluster 시스템 유지 – ex) PowerVm을 이용한 test환경 구축 • 문서화된 복구 절차 - test를 통해 복구절차와 예상되는 결과를 문서화 해서 활용

  47. Documenting the Environment with OLPW • Online Planning Worksheets: HTML report file

  48. What about PowerHA and distance? • Two options, Remote PowerHA or PowerHA/XD • Remote PowerHA – Systems see same copy of data (shared access to same LUNs) – LVM mirroring (with the optional but recommended Cross-site LVM Mirroring configured) keep copies in sync across sites – System-down condition is a site-down condition – Cross-site LVM Mirroring facilitates integration/reintegration, managing LVM mirror copy consistency between sites • PowerHA/XD – Systems see “own” copy of data that is replicated – Data replication mechanism keeps copies in sync across sites • GLVM (Geographic Logical Volume Manager) • Metro-Mirror in DS8000 or SVC – Local fallover option can be employed to keep a system-down condition local to the site – PowerHA/XD facilitates the integration/reintegration, including replication role reversal, between sites • Again, networking (IP/non-IP) used for monitoring in both cases

  49. 목차 1. HACMP 개요 2. 요소별 고려사항 3. 실 고객 구성 사례 4. HACMP with PowerVM 5. Do’s and Don’ts 6. 첨부 Contents 3

  50. Case #1 – A사 Cluster Name: A사 2 Node Cluster (A + S) IP Aliasing Etherchannel : (A + B) Rs232/MNDHB : 모두 사용 Application Monitoring : 사용 Takeover Test : 안함 Application Monitoring timeout이 짧아서 fallover 되는 도중에 다시 fallback을 시도하는 현상이 있었음(duration time을 늘려서 정상 조치함) Network: net_ether0 NODE A NODE B RG1(NodeA, NodeB) Standby Node Service IP Volume Group Production App Network: rs232_net Network: diskhb_net Storage Subsystem

More Related