Riverbed Certified Solutions Professional

Riverbed Certified Solutions Professional (RCSP) Study Guide pdf
Riverbed Certified Solutions Professional (RCSP) Study Guide Version 1.0.13 pdf
Riverbed Certified Solutions Associate (RCSA) Study Guide pdf

Trainings, presentations, webcast, videos
Enhance Your Riverbed Deployment 2011 – An Online Workshop
ABCDEs of WAN Optimization
Steelhead Mobile Demo
Whitewater Demo
Configure Backup Exec with Whitewater
Configure NetBackup with Whitewater
Configure Whitewater with vRanger
Cascade
Cloud Steelhead
Desktop Virtualization
Disaster Recovery
Private Cloud Consolidation
Riverbed Services Platform
Steelhead Mobile
Steelhead WAN Optimization
Virtual Steelhead
Network Visibility
WhiteWater
Quick Bits: A Complete WDS Solution
CONSOL Energy optimizes network performance
Riverbed CSX
AVST deployed Cloud Steelhead™ from Riverbed

Global Catalog Servers

Global Catalog Servers contain a partial replica for every object in Active Directory. A Global Catalog Server is used to find objects in any domain in the forest. Any Domain Controller can be made into a Global Catalog Server.

Global Catalog Servers are used to find objects in any domain in the forest but it should be remembered that this does not give the user access to that object. Unless the user has the correct permissions they will not be able to access resources in other domains.

Global Catalog Servers also contain information about groups that span across domains and services that work at the forest level.

How to change a Domain Controller to a Global Catalog Server 04:18
Using the admin tool Active Directory Users and Computers to navigate to the computer account for your Domain Controller. By default this will be located in the Domain Controllers OU.
Open the properties for the Domain Controller and select the button NTDS settings.
Deselect or select the tickbox Global Catalog. Windows will do the rest.

Reasons to deploy Global Catalog Servers
Reason 1
Domain Controllers generate a security token for a user when they first login. If the user is in a group that spans multi–domains, that Domain Controller will need to contact a Global Catalog to get information about that group.
Reason 2
If a user logs in using a Universal Principal Name (UPN), that is, they log in using a user name in the form of username@domainname, a Domain Controller will need to access a Global Catalog Server before the log in is completed.
Reason 3
Global Catalog Servers work as an index to the forest. If you perform any searches on the forest you will need to contact a Global Catalog Server.
Reason 4
Microsoft recommends that any network that is separated by a Wide Area Network have a Global Catalog Server deployed at that location. This will ensure that users can log on if the Wide Area Network is down. In order for a computer to contact a Global Catalog Server, ports 389 (LDAP) and 3267 (Global Catalog) need to be opened. If these ports are not open then the user will not be able to use the remote Global Catalog Server.
Reason 5
Some software requires a Global Catalog Server in order to run. Exchange is a big user of the Global Catalog Server. If you have a decent amount of Exchange users on your network, you should consider deploying a Global Catalog Server close to these users.

Reasons not to deploy a Global Catalog Server
Global Catalog Servers put more load on the server in the form of searches and lookups from the client.
Global Catalogs need to keep their index up to date. This requires more network bandwidth.
In order to store the Global Catalog Server, you are required to have additional hard disk space on your server.

Planning and Designing Exchange 2010

One of the most frequent asked questions is defining storage configuration for Exchange 2010, what type of disk to go with and what type of RAID should be used. In reality most of these will depend upon your IT spending at the time when you plan or purchase this equipment.

If you are looking for advice or justification as what to purchase or perhaps doing design you might want to start reading links I am providing. Most of these generic questions have been answered in great details. Pay attention to “Best Practices” section the most (- :

Most of the best practices familiar but including DAG and redundancy less to worry if you go with redundant logs and databases.

Database size Supported up to 16 TB as best practice is less than 2 TB and provision 120% calculated maximum database size. In reality the major changes in ESE database and huge reduction on I/O requirements made Exchange more to give when it comes to databases. This is one of the primary reason Exchange even added “Archived database” out the box, since there is no longer I/O fear exist in a way in Exchange 2010 if you compare to previous versions. Still selecting fast disk should be preferred and give as much memory and CPU power to Exchange servers in reasonable measures and fallowing MS best practices as guidelines for each role and capacity.

• Mailbox Storage Design Process
• http://technet.microsoft.com/en-us/library/ff367907.aspx
• Understanding High Availability Factors
• http://technet.microsoft.com/en-us/library/ee832790.aspx
• Understanding Storage Configuration
• http://technet.microsoft.com/en-us/library/ee832792.aspx
• Understanding Exchange 2010 LUN Architecture
• http://technet.microsoft.com/en-us/library/ee832794.aspx
• Exchange 2010 Mailbox Server Role Design Example
• http://technet.microsoft.com/en-us/library/ee832789.asp

Cheers,

Best regards,

Oz Casey , Dedeal

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