Planning HA/DR System for Exchange 2007

Đã khá lâu rồi tôi mới lại tiếp tục bài viết thứ hai về Disaster Recovery cho Exchange 2007 sau bài viết đầu tiên về HA cho Exchange 2007. Tôi thực hiện bài viết này khi nhận thấy các khách hàng Enterprise bắt đầu có nhiều nhu cầu về DR cho hệ thống thư tín Exchange vốn dĩ càng lúc càng trở nên quan trọng. Ngoài ra bài viết này cũng giải tỏa phần nào thắc mắc về giải pháp DR cho Exchange 2007 từ các Microsoft Partners mà tôi từng tiếp xúc.

Trước khi đi vào chi tiết, tôi xin có vài lời giới thiệu về thuật ngữ Disaster Recovery để rộng đường cho phần trình bày phía sau. Disaster Recovery tiếng việt nghĩa là khôi phục sau thảm họa (tự nhiên/con người/máy móc) theo định nghĩa là các quy trình,chính sách liên quan đến câu chuyện chuẩn bị cho việc phục hồi hay bảo đảm tính liên tục của những thành phần hạ tầng quan trọng đối với doanh nghiệp mà trong đó hạ tầng CNTT là một thành tố ko thể thiếu. Disaster Recovery Planning là một phần ko bao giờ thiếu trong câu chuyện hoạch định Business Continuity Planning. Mà đã nói về BCP thì ai cũng hiểu câu chuyện security cuối cùng quay về chuyện đảm bảo cho Business Up and Running. Nói đến DR người ta hay nói về 2 thành tố Khoảng Thời Gian Mất Dữ Liệu (Recovery Point Object – RPO) và Thời Gian Tiêu Tốn Cho Phục Hồi Dữ Liệu (Recovery Time Object – RTO). Vì vậy có thể nói việc hoạch định HA/DR là một phần rất quan trọng trong các giải pháp tổng thể về an ninh đặc biệt với các chuẩn an ninh như ISO 27000/SOX.

Khá nhiều nhầm lẫn giữa 2 thuật ngữ HA (High Availability) và DR (Disaster Recovery) nên tôi cũng xin brief sơ qua như sau: HA có thể hiểu là giải pháp nhằm ngăn chặn downtime hệ thống xảy ra nhằm đảo bảo tính ổn định của hệ thống (Availability) trong khi DR lại là giải pháp nhằm sử lý những sự cố mà HA không thể giải quyết rốt ráo như mất điện/động đất/thiên tai và DR không nhằm ngăn chặn downtime mà chỉ cốt sao để rút ngắn thời gian downtime hệ thống xuống mức thấp nhất có thể. Vì thế ta sẽ thấy các giải pháp HA sẽ có khả năng automatic failover/failback trong khi ở các giải pháp DR thường chỉ là manual failover/failback mà thôi.

Trên thực tế qua tiếp xúc với nhiều khách hàng và partner tôi nhận thấy rằng mọi người mau chóng vồ vập vào các giải pháp công nghệ để xử lý cho vấn đề HA/DR Exchange mà lại quên đi rằng phần hoạch định cho nó mới là cốt lõi. Để hoạch định cho câu chuyện HA/DR chúng ta cần phải xác định từ nhu cầu liên quan đến Business Continuity để từ đó xác định ra danh sách các rủi ro đồng thời dựa trên yếu tố kinh phí và mức độ chấp nhận rủi ro của doanh nghiệp để hoạch định ra các giải pháp để xử lý cho những rủi ro cần được triệt tiêu. Đối với hệ thống thư tín Exchange, chúng ta có thể tự trả lời các câu hỏi sau để xác định các rủi ro cần triệt tiêu:

1. Mức độ dịch vụ nào cần được tuân thủ khi trung tâm dữ liệu chính ngưng hoạt động hoàn toàn?
2. Người dùng sẽ cần dữ liệu mail và dịch vụ mail hay cả hai ?
3. Thời gian tối đa (RTO) mà người dùng chấp nhận được khi hệ thống thư tín ngừng hoạt động ?
4. Khi hệ thống thư tín tại trung tâm dữ liệu chính ngừng hoạt động thì có bao nhiêu người bị tác động và bao nhiêu trong số đó cần được đảm bảo sự thông suốt của dịch vụ/dữ liệu thư tín ?
5. Khi có sự cố xảy ra thì quá trình khôi phục từ phía người dùng sẽ ra sao ? (Người dùng phải hiệu chỉnh Outlook profile, người dùng phải restart outlook, IT phải flushdns trên máy tính đầu cuối….)
6. Mức độ cam kết dịch vụ (SLA) trong câu chuyện khởi động trung tâm dữ liệu dự phòng sẽ là gì ?
7. Quá trình khôi phục trở lại hệ thống thư tín khi trung tâm dữ liệu chính được khôi phục sẽ như thế nào ?
8. Tài nguyên dành cho hệ thống thư tín ở trung tâm dữ liệu dự phòng sẽ ở hình thức passive (chỉ phát huy tác dụng khi sự cố ở DC chính xảy ra) hay active (sẽ được sử dụng song song cùng với DC chính chứ không đơn thuần là backup).

Sau khi đã có được feedback từ phía người người cuối (COO lẫn những người phụ trách các phòng ban chẳng hạn) và CIO từ bộ survey bên trên, chúng ta sẽ quyết định xem các rủi ro về mặt kĩ thuật có thể xảy ra với hệ thống Exchange nào dưới đây cần phải triệt tiêu theo thứ tự ưu tiên:

• Các tác nhân có thể tạo ra rủi ro cho hệ thống Exchange:

  1. Phần mềm bị hỏng chẳng hạn đơn giản services Exchange system attendant không start được hoặc service IIS w3vc trên Client Access Server bị lỗi chẳng hạn.
  2. Phần cứng phục vụ cho hệ thống thư tín bị hỏng hóc chắng hạn như CPU hoặc bus controller của Mailbox Server bị hư hoặc RAID Controller link đến LUN chứa Mailbox DB hoặc Log bị hư chẳng hạn.
  3. Database bị hỏng do lỗi ứng dụng hoặc lỗi phần cứng khi lưu trữ hoặc replicate chẳng hạn.
  4. Kết nối mạng heartbeat giữa các node cluster bị hỏng hoặc kết nối WAN giữa 2 DataCenter bị hỏng.
  5. Các lỗi do con người gây ra hoặc vô tình hoặc cố ý làm mất dữ liệu thư tín như mail item chẳng hạn.
  6. Sự cố virus có thể khiến các role của Exchange bị tê liệt dẫn đến ngưng trệ dịch vụ hệ thống chẳng hạn.
  7. Các hệ thống hạ tầng liên quan bị ảnh hưởng như DNS bị lỗi hoặc DC/Global Catalog ở site có Exchange Server ngừng hoạt động.
  8. Các sự cố về thảm họa như chập điện/cháy nhà/hỏng hệ thống cooling/động đất/khủng bố…

Tại thời điểm này chúng ta đã có thể bắt tay vào việc hoạch định giải pháp kĩ thuật để ngăn ngừa và giảm thiểu downtime gây ra từ các rủi ro đó. Ở đây tôi sẽ liệt kê ra tất cảc các rủi ro kĩ thuật và giải pháp xử lý đi kèm để mọi người dễ theo dõi và hoạch định. Trên thực tế thì chúng ta nên tập trung mạnh vào các phần liên quan đến máy chủ Mailbox Server để đảm bảo toàn vẹn dữ liệu trước tiên sau đó mới đến đảm bảo dịch vụ thư tín qua việc bảo vệ các vai trò khác của Exchange Server 2007.

• Các rủi ro kĩ thuật đối với Exchange và giải pháp kĩ thuật tương ứng:

  1. Mất mát mail item:
     1. Chính sách xóa retention cho mail item của Exchange 2007 (mặc định là 14 days).
     2. Sử dụng Recovery Storage Group để khôi phục Mail item bằng các giải pháp backup VSS như System Center DPM 2007 chẳng hạn.(***)
     3. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho các Role Edge/Hub/Mailbox.(***)
• Mất mát cả mailbox của người dùng:
  1. Chính sách xóa retention cho Mailbox của Exchange 2007.
  2. Sử dụng Recovery Storage Group để khôi phục Mailbox bằng các giải pháp backup VSS như System Center DPM 2007 chẳng hạn.(***)
  3. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho các Role Edge/Hub/Mailbox.(***)
• Mất mát cả mailbox database:
  1. Sử dụng VSS Clone cho Mailbox Database nếu lưu trữ trên SANs.
  2. Sử dụng các giải pháp RAID để scale up cho hệ thống lưu trữ mailbox DB và Log.
  3. Sử dụng LCR Cluster của Exchange để bảo vệ Mailbox DB và Log ở mức độ Disk.
  4. Sử dụng CCR Cluster của Exchange để bảo vệ Mailbox DB và Log ở mức độ Server.
  5. Sử dụng Recovery Storage Group để khôi phục Mailbox bằng các giải pháp backup VSS như System Center DPM 2007 chẳng hạn.(***)
  6. Sử dụng SCR cùng site với tính năng Database portability để chuyển mailbox sang máy chủ Mailbox khác.
  7. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho các Role Edge/Hub/Mailbox.(***)
• Mất mát cả public folder database:
  1. Sử dụng VSS Clone cho Public Folder Database nếu lưu trữ trên SANs.
  2. Sử dụng các giải pháp RAID để scale up cho hệ thống lưu trữ Public Folder DB.
  3. Sử dụng LCR Cluster của Exchange để bảo vệ Public Folder DB ở mức độ Disk.
  4. Sử dụng CCR Cluster của Exchange để bảo vệ Public Folder DB ở mức độ Server.
  5. Sử dụng Recovery Storage Group để khôi phục Public Folder bằng các giải pháp backup VSS như System Center DPM 2007 chẳng hạn.(***)
  6. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho các Role Edge/Hub/Mailbox.(***)
• Mất mát cả mail storage group:
  1. Sử dụng VSS Clone cho LUN chứa data của Mail Storage Group nếu sử dụng SANs.
  2. Sử dụng các giải pháp RAID để scale up cho hệ thống lưu trữ data của Mail Storage Group.
  3. Sử dụng LCR Cluster của Exchange để bảo vệ data của Mail Storage Group ở mức độ Disk.
  4. Sử dụng CCR Cluster của Exchange để bảo vệ data của Mail Storage Group ở mức độ Server.
  5. Sử dụng Recovery Storage Group để khôi phục Mail Storage Group bằng các giải pháp backup VSS như System Center DPM 2007 chẳng hạn(***)
  6. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho các Role Edge/Hub/Mailbox.(***)
• Mất mát cả Exchange Mailbox Role Server (*):
  1. Dữ liệu + Dịch Vụ:
     1. Sử dụng các giải pháp về scale up phần cứng như tăng CPU/ECC cho RAM/RAID cứng/Dual Fan/Dual NIC/Dual HBA Controller/Dual SANs Switch/Dual SANs Storage.
     2. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho Role Mailbox. (***)
     3. Sử dụng DPM SRT để backup cả OS + SystemState và dùng Recovery Storage Group bằng DPM 2007 để khôi phục các Storage Group để làm HA Local. (***)
  2. Dữ liệu:
     1. Sử dụng giải pháp về scale out SCC (Shared Storage) với SANs cho HA local và SANs Replication cho DR Site. (**)
     2. Sử dụng giải pháp scale out kết hợp giữa SCC làm HA tại local site và SCR để làm DR (SCC + SCR) sang DR DataCenter. (**)
     3. Sử dụng giải pháp scale out CCR local site giữa 2 node cluster Mailbox Server để làm HA và CCR mở rộng giữa 2 node cluster Mailbox Server nằm ở 2 DataCenter khác vùng vật lý cùng AD Site và khác subnet (Stretched CCR Cluster) để làm DR.
     4. Sử dụng giải pháp scale out kết hợp giữa CCR làm HA tại local site và SCR để làm DR sang DR DataCenter theo dạng Active/Passive DataCenter Mode tức là hệ thống DR tại DR Site chỉ có tác dụng khi DC chính down.
     5. Sử dụng giải pháp scale out kết hợp giữa CCR làm HA tại local site và SCR để làm DR sang DR DataCenter theo dạng Active/Active DataCenter Mode tức là 2 hệ thống DC sẽ hoạt động song song và backup lẫn nhau.
     6. Sử dụng giải pháp consolidate cluster với Hyper-V giữa các VM Mailbox Exchange với Sans để HA cho local site hoặc Hyper-V với SANs Replication cho các VM Exchange Mailbox Role Server giữa 2 hệ thống SANs nằm ở 2 DC để DR.
• Dịch vụ:
  1. Bản chất thông tin cấu hình của Mailbox 99% nằm trong Database AD do đó để đảm bảo khả năng khôi phục cho dịch vụ Exchange thì cần đảm khảo độ ổn định của database AD.
  2. Sử dụng switch setup /m:RecoverServer để khôi phục dữ liệu cấu hình của Mailbox Role từ AD.
• Mất mát cả Exchange Hub Transport Role Server:
  1. Sử dụng các giải pháp về scale up phần cứng như tăng CPU/ECC cho RAM/RAID cứng/Dual Fan/Dual NIC.
  2. Sử dụng giải pháp scale out bằng cách triển khai cùng lúc nhiều node Hub Transport để HA local site và đặt thêm server Hub Transport tại DR Site để DR.
  3. Sử dụng giải pháp backup systemstate và config data bằng System Center DPM 2007.(***)
  4. Do 99% dữ liệu cấu hình của HT Role nằm trong database AD do đó có thể sử dụng switch setup /m:RecoverServer để khôi phục cấu hình cho HT Role từ DB AD.
  5. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho Role Hub Transport.(***)
• Mất mát cả Exchange CAS Role Server:
  1. Sử dụng các giải pháp về scale up phần cứng như tăng CPU/ECC cho RAM/RAID cứng/Dual Fan/Dual NIC.
  2. Sử dụng giải pháp scale out bằng cách triển khai NLB các node CAS local để HA local site và triển khai thêm CAS ở DR Site không dùng NLB để DR.
  3. Thông tin cấu hình của CAS nằm trong AD và IIS Metadata. Tuy nhiên khi sử dụng setup /m:RecoverServer thì ko nên restore IIS Medata mà nên dùng IIS change log để cấu hình lại.
  4. Vì CAS không phải là nơi mà mai chạy qua mà chỉ là điểm cung cấp truy cập nên chỉ cần sử dụng các giải pháp chống virus cho Endpoint như Microsoft Forefront Client Security.(***)
• Mất mát cả Exchange Edge Transport Role Server:
  1. Sử dụng các giải pháp về scale up phần cứng như tăng CPU/ECC cho RAM/RAID cứng/Dual Fan/Dual NIC.
  2. Sử dụng giải pháp scale out bằng cách triển khai nhiều Server Edge Transport local kết hợp sử dụng DNS MX Record giữa các server này để HA local site và cũng như triển khai thêm Edge Transport tại DR Site và thay đổi MX Record để làm DR .
  3. Sử dụng giải pháp backup systemstate và config data bằng System Center DPM 2007.(***)
  4. Sử dụng các powershell script nhưExportEdgeConfig.ps1 và ImportEdgeConfig.ps1 có sẵn trong thư mục cài đặt của Exchange để backup/restore thông tin cấu hình.
  5. Sử dụng giải pháp chống virus/spam Microsoft Forefront for Exchange cho Role Edge Transport.(***)
• Mất mát hệ thống hỗ trợ backend như AD/DNS:
  1. Có DR Plan cụ thể cho hạ tầng AD/DNS với các giải pháp scale out/scale up/antivirus cũng cần được quan tâm tương xứng nhằm đảm bảo phải luôn có 1 DC/GC và DNS để phục vụ cho hạ tầng Exchange khi xảy ra Disaster.
• Mất mát hệ thống hỗ trợ backend như phần cứng/tưởng lửa/hạ tầng DC:
  1. Có DR Plan cụ thể cho các phần hạ tầng này nhằm đảm bảo mọi thứ ready khi cần recovery sang DR Site.

* Tại sao không sử dụng các phải pháp relay database: Sẽ có câu hỏi như vậy được đặt ra trong buổi brainstorm về giải pháp DR liên quan đến role Mailbox Server. Vì vốn dĩ giải pháp scaleout CCR/SCR sử dụng công nghệ log shipping nên traffic replication sẽ là tối ưu so với phương pháp relay database.

** Sử dụng SANs-to-SANs replication Solution hay SANs-to-SCR replication: câu trả lời sẽ tùy thuộc vào kinh phí và yêu cầu về RTO/RPO cho hệ thống Exchange. Nếu kinh phí là yếu tố quan trọng trọng thì nên cân nhắc sử dụng SANs-to-SCR vì công ty sẽ không phải chi nhiều tiền cho license Geo-cluster ở giải pháp SANs-to-SANs replication.

*** DPM + Forefront for Exchange/Forefront Client Security: việc sự dụng các giải pháp này sẽ cần kết hợp với các giải pháp khác trong từng nhóm rủi rỏ để đảm bảo RPO/RTO

• Best Practices để đảm bảo RPO/RTO cho DR hệ thống Exchange 2007:

Giải pháp kĩ thuật thì có rất nhiều và rất đa dạng và thậm chí nó quá tinh xảo đến mức dễ khiến chúng ta xa đà vào nó mà quên mất mục tiêu chính là chúng được đẻ ra để giúp chúng ta đạt được RPO/RTO cho DR Exchange. Vì vậy chúng ta nên có những kế hoạch thử nghiệm và tập huấn nhân sự sao cho giải pháp kĩ thuật thật sự phát huy đúng năng lực và phù hợp nhất với doanh nghiệp cả về yêu cầu RTO/RPO Business Continuity lẫn yếu tố kinh phí. Sau đây tôi xin liệt kê một số thông tin mà nhóm làm DR Exchange cần thực hiện:

1. Kiểm tra công năng lực giải pháp kĩ thuật nhằm đảo bảo SLA khi Disaster xảy ra. Công đoạn Proof Of Concept (POC) cần được thực hiện và document chi tiết để đảm bảo giải pháp công nghệ là phù hợp. Vì đôi khi không cần sử dụng đến các hệ thống SANs và chi phí license đắt tiền cho SANs Replicaton mà chỉ sử dụng các tính năng Out Of Box về HA/DR của Exchange 2007 như CCR/SCR vẫn có thể đảm bảo SLA.

2. Tập huấn định kì các giải pháp ứng phó khi xảy ra các sự cố. Không có những con người sẵn sàng cho các tình huống xấu với hệ thống Exchange thì những cam kết của giải pháp công nghệ trị giá hằng triệu đô cũng chỉ là con “zero”. Câu chuyện tập huấn không chỉ mang tính định kì theo tháng hay theo quý mà còn phải có sự tham gia của cả người dùng lẫn quản trị hệ thống vì khi Disaster xảy ra đôi khi sẽ cần nhiều sự tương tác từ phía người dùng cuối chứ không phải trong suốt như lời quảng bá của một số giải pháp công nghệ.

3. Đảm bảo dữ liệu backup và đường truyền sẵn sàng. Rất nhiều giải pháp Backup CDP (Continuous data protection) còn được biết đến như zero data loss nhưng khi restore dữ liệu thì lại không hoạt động do đó câu chuyện đảm bảo dữ liệu backup sẵn sàng là điều tối quan trọng. Đường truyền/IP/Certificate cũng là những yếu tố thường bị bỏ qua trong kế hoạch DR. Chẳng hạn mọi thứ đều sẵn sàng nhưng khi failover sang DR Site mà doanh nghiệp lại không có IP tĩnh cho Server Edge Transport khiến người dùng không thể gửi/nhận thư tín với bên ngoài.

4. AD/DNS là xương sống cho hệ thống Exchange. Điều này phải luôn được đề cao trong giải pháp DR vì nếu doanh nghiệp muốn đảm bảo RTO/RPO cho quá trình failover/failback data và dịch vụ thư tín xuông sẻ thì AD/DNS luôn cần phải song hành với Exchange.

5. Sử dụng ”súng nhỏ” trước khi dùng “súng to” trong quá trình xử lý các rủi ro kĩ thuật cho Exchange. Đôi khi Exchange Admin quá vội vã dùng để dữ liệu backup để khôi mailbox database khi có thể sử dụng các công cụ troubleshoot datbase và DR như Exchange Performance Troubleshooting Analyser (ExPTA)/Exchange Disaster Recovery Analyser (ExDRA). Hoặc dùng dữ liệu backup để khôi phục mail item cho người dùng mà quên đi tính năng retention vốn có của Exchange Mailbox Database.

6. Không chỉ DR hệ thống Exchange mà còn phải DR cả chuyên gia Exchange. Không ít doanh nghiệp có những hệ thống DR siêu đắt tiền nhưng họ lại không có kế hoạch dự phòng nhân sự quản trị hệ thống đó dẫn đến khi nhân sự chuyên trách Exchange ra đi thì không ai có thể khỏa lấp khoảng trống dẫn những kế hoạch chuẩn bị DR trở nên vô nghĩa. Vì vậy doanh nghiệp phải có kế hoạch phòng bị cả nhân sự lẫn đảm bảo document và quy trình DR bài bản cho từng rủi ro (xem các template quy trình bên dưới).

7. Phòng bệnh hơn chữa bệnh. Để SANs hỏng thì có vẻ khó nhưng để HBA Controller hỏng thì có vẻ dễ hơn nhiều và nếu không có sự phòng bị chủ động thì thời gian downtime sẽ là như nhau. Vì vậy không chỉ có sự chuẩn bị cho quá trình phản ứng khi Disaster xảy ra mà nên có sự chuẩn bị chủ động cho tất cả những rủi ro có thể xảy ra cho hệ thống Exchange 2007 và một trong số các công cụ đảm bảo SLA cho hệ thống Exchange đó là System Center Operation Manager 2007 R2. Với SCOM 2007 R2 cho phép IT giám sát hệ thống Exchange theo mô hình đối tượng rất dễ dự đoán và phản ứng khi có lỗi xảy ra đồng thời với SCOM 2007 R2 IT có thể load bộ Management Pack miễn phí để lấy những best practice về quản lý hệ thống Exchange 2007.

Qua mô tả về các rủi ro kĩ thuật và các giải pháp kĩ thuật tương ứng cho Exchange tôi tin rằng mọi người đều đồng ý rằng để có một giải pháp tổng thể về DR đảm bảo cả RPO lẫn RTO hoàn toàn không hề đơn giản. Nó cần được kết hợp giữa nhiều loại công nghệ lẫn người chuyên trách cho phần công nghệ đó như AD/DNS/Network/SANs Storage/Backup/DataCenter. Người phụ trách phần DR Exchange sau khi đã hoàn tất giải pháp tổng thể cần viết thành các quy trình chuẩn để xử lý failover/failback cho từng rủi ro kĩ thuật. Dưới đây là ví dụ mẫu chúng ta có thể tham khảo:

vncson