Hướng dẫn hyper-v replication đồng bộ 2 server 2023
I know there has been some articles pertaining to the concerns and it is a big NO NO. I'm wondering over the years with the latest OS versions and numerous patches by Microsoft, does this theory still applies ? Below are some of the old articles that i have read but with the latest versions , does this still applies ? https://www.starwindsoftware.com/blog/hyper-v/combining-hyper-v-dc-role-server-bad-idea/ (3 years) https://www.altaro.com/hyper-v/reasons-not-to-make-hyper-v-a-domain-controller/ (9 years ago) Its a common practices where usually company commence building up an infrastructure with 2 core mid range servers (Datacenter versions) and configure Hyper V host Reading best practices by Microsoft indicating that the domain controller should be in both a physical and virtualized environment. i Intend to have at least 2 hyper V hosts while i configure replication for our VMs. Not possible for me to have the 3rd server just for the sake of having a physical domain controller. Or should a physical DC be completed disregarded and just have pri/sec domain controllers on VMs? Appreciate your thoughts Thank you. asked Dec 18, 2023 at 13:56 2 You could also have a domain controller in Azure and one on your hyper-v host. I think the advice to have a psychical dc is a bit outdated. Just make sure you don't live migrate the dc from host to host. And pay good attention to the time sync when using a hyper-v guest as DC But if you require replication, that means that the DC needs to be up and running before the Hyper-v starts so that would mean either a dc on hardware or in Azure answered Dec 20, 2023 at 4:39 TurdieTurdie 1,7231 gold badge9 silver badges14 bronze badges After Windows Server 2012 it was safer to have a virtual DC. Windows Server 2012 and later support the implementation of virtualized domain controllers (DCs) with safeguards to prevent update sequence number (USN) rollback on virtual DCs and the ability to clone virtual DCs. Hyper-V consolidates different server roles onto a single physical computer. For more information, see Safely virtualizing Active Directory Domain Services (AD DS). Ref: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controllers-hyper-v Hyper-V Replica là một tính năng hoàn toàn mới trên Windows Server 2012. Nó là giải pháp “Disaster Recovery”. Gíup nhanh chóng khắc phục và phục hồi khi xảy ra sự cố với các Virtual Machine trong Hyper-V. Một số IT Pro thường nhầm lẫn giữa Hyper-V Replica và Hyper-V Live Migration. Hyper-V Replica cho phép tạo một bản sao các máy ảo từ bên Primary Site sang bên Replica Site, có thể phục hồi trong trường hợp khẩn cấp (Disaster). Còn Hyper-V Live Migration chỉ đơn giản là move (di chuyển) máy ảo từ Hyper-V server này sang Hyper-V server khác. Máy ảo sẽ chạy ở Primary Site và Replica Site là nơi chứa bản sao dự phòng của máy ảo bên Primary Site. Việc replicate các máy ảo có thể là đường LAN/WAN. Hyper-V Replica tương thích hoàn toàn với bất kỳ Server, network hoặc storage của các hãng khác nhau.
Trong Windows Server 2012, nhân Hypervisor (VMMS.exe) được tích hợp thêm thành phần Replica (Components). Và gọi là module “Replica Engine”, trong module này có rất nhiều thành phần, nhưng có 4 thành phần chính giúp hình thành nên Hyper-V Replica. Bao gồm : Replication Manager, Replication Tracker, Network Module, Change Tracking”. 1. Replication Manger (RM) Là thành phần quan trọng nhất, chịu trách nhiệm quản lý và thực thi quá trình replication giữa Hyper-V Primary Server và Hyper-V Replica Server. Thực hiện các chức năng cần thiết để đảm bảo việc replicate một cách hiệu quả. Gồm 4 hành động chính :
Ngoài ra còn có các hành động khác như : giám sát trạng thái của các máy ảo, thực hiện nén, mã hóa và đảm nhận các chức năng Standard-Replica, Application-Consistent Replica. Giữ cho việc replicate được thực hiện đầy đủ đúng theo lịch trình, báo cáo về thông tin của lần replicate cuối cùng. 2. Change Tracking Sau khi các máy ảo bên Primary Server được kích hoạt tính năng Replication. Lúc này Change Tracking sẽ chịu trách nhiệm track (theo dõi sát) các thay đổi của file VHD của từng máy ảo. Khi phát hiện có thay đổi nào, Change Tracking lập tức forward thông tin đến báo cho Replication Manager biết. Replication Manager sẽ đẩy xuống hành động Delta Replication Handler để thực thi chức năng Standard-Replica hoặc Application-Consistent Replica. Những thông tin tracking này được Replication manager lưu trong cùng thư mục chứa máy ảo và dưới dạng là .HRL. Khi quá trình replication xảy ra, hệ thống sẽ gửi đi các file .HRL này. 3. Replication Tracker Sau khi các file .HRL đã được Replication Manager tạo ra đầy đủ và sẵn sàng để gửi đi. Lúc này RM sẽ thông báo cho Replication Tracker (RT), để RT thực hiện nhiệm vụ gửi các file này đến Replica Server. Mặc định là 5 phút và không thể thay đổi thời gian này. RT chỉ chịu trách nhiệm gửi các file .HRL. 4. Network Module Là module được đề cập sau cùng, là kết nối mạng giữa Primary Site và Replica Site, bao gồm các service :
2 bên Site sẽ có 2 thành phần: HTTP Client và HTTP Listener. Cả 2 thành phần này hoạt động trên giao thức HTTP hoặc HTTPS. HTTP Client dùng để gửi các gói HRL file và HTTP Listener sẽ lắng nghe hành động Initial Replication và Delta Replication. Trước khi các file HRL được Primary Site gửi đi đến Replica Site, Replica Site phải được chứng thực thành công với Primary Site (việc chứng thực được thực hiện dựa trên giao thức HTTP hoặc HTTPS). Việc chứng thực được thực hiện trong lúc bạn cấu hình replication, và các chu kỳ replicate tiếp theo sẽ không cần chứng thực lại. Sau khi chứng thực thành công, lúc này Replica Site mới thiết lập kết nối và nhận các file .HRL mà Primary Site gửi đến. Sau khi nhận các file .HRL, Replica Site sẽ gửi ACK lại để xác nhận cho Primary Site biết nó đã nhận được và bắt đầu đưa vào xử lý.
Hyper-V Replica trong Windows Server 2012 R2 khác với Windows Server 2012 là hỗ trợ thêm option Replicate với thời gian 30s và 15 phút, ngoài ra còn có tính năng Replicate Chain, có thể hiểu HOST A (Primary Site) replicate máy ảo sang HOST B (Replica Site), HOST B tiếp tục replicate sang máy ảo HOST C (IaaS, Replica Site 2) mà tôi hay gọi là Replicate mắt xích. Lab Hyper-V Replica Non-Cluster with Domain Membership
Mặc định Hyper-V Replica cho phép tối đa 15 bản recovery point (snapshot), có 2 cơ chế tạo một Recovery point :
+ Coverage provided by additional recovery points (in hours) : là cơ chế backup dạng “Standard Replica”. Thực hiện Full backup theo chu kỳ. + VSS (Volume Shadow Copies) : là cơ chế backup bổ sung, dạng “Application-Consistent”, dùng application VSS để sao lưu tùy theo thời gian ta thiết lập.
Thứ nhất, Bạn không nên nhầm lẫn giữa triển khai Failover Cluster và Hyper-V Replica. Failover Cluster giúp cho hệ thống luôn ở trong trạng thái sẵn sàng (High Availability) bất cứ lúc nào, còn Hyper-V Replica chỉ là một cơ chế khắc phục sự cố khi xảy ra (Disaster Recovery) và chỉ là tạm thời. Người quản trị cứ nhầm lẫn là Hyper-V Replica cũng giống Failover Clustering, thế nên họ ưu tiên triển khai Hyper-V Replica hơn. Trong thực tế, chúng ta nên triển khai Failover Clustering. Như tôi đề cập ở trên, Hyper-V Replica thiết kế ra chỉ giải quyết vấn đề “Disaster Recovery” (khắc phục sự cố, thảm họa), cho phép phục hồi máy ảo một cách nhanh chóng. Nếu các máy ảo Primary Site bị chết, thì các máy ảo copy bên Replica Site sẽ enable lên và chạy (việc này bạn phải thực hiện bằng tay), giúp phục hồi hệ thống nhanh nhất để không làm gián đoạn . Giả sử trong trường hợp Replica Site cũng chết, thì coi như không thể phục hồi và doanh nghiệp sẽ bị downtime liên tục. Kết luận, Hyper-V Replica chỉ phục hồi tạm thời và về lâu dài thì triển khai giải pháp Failover Cluster vẫn hay hơn. Thứ hai, rất nhiều người quản trị nghĩ rằng Hyper-V Replica thực chất là một phương pháp backup (do nó ánh xạ 1:1) và bỏ quên các giải pháp backup máy ảo theo kiểu truyền thống trong Hyper-V. Đó thực sự là sai lầm. Sau đây là bảng so sánh giữa Failover Cluster, Hyper-V Replica, và phương pháp Backup. Cluster Hyper-V Replica Backup Thay thế cho Cluster N/A No No Thay thế cho Hyper-V Replica No N/A Yes Thay thế cho phương pháp backup No No N/A Như bạn thấy, phương pháp backup có thể thay thế cho Hyper-V replica, nhưng nếu xét ngược lại thì hoàn toàn không thể. Hyper-V Replica chỉ cho phép tối đa 15 bản snapshot cho cả 2 cơ chế “Standard Replica” hoặc “Application-Consistent”. Nếu sếp bạn yêu cầu phải giữ các bản sao trong vòng một tháng, điều đó thực sự khó khăn. Còn nữa, Hyper-V Replica không có đầy đủ các thuộc tính sao lưu ở dạng nâng cao hơn là các phương pháp backup. Do đó cần phải có một phương pháp backup truyền thống. Ví dụ như sản phẩm Altaro Hyper-V Backup, cho phép bạn backup và tạo ra vô số bản snapshot cho từng thời điểm. Còn đối với Và an toàn hơn hết trong trường hợp cả 2 Hyper-V Primary Site và Hyper-V Replica đều chết. Thì backup bằng truyền thống (off-site) sẽ còn lưu giữ lại các máy ảo, và việc bạn cần làm là chỉ cần tạo ra một Hyper-V server mới sau đó import các máy ảo này vào. Hyper-V Replica cho phép bạn giả lập môi trường và test thử khả năng chịu lỗi trước khi có sự cố xảy ra. Giúp bạn an tâm hơn sau khi cấu hình. Tiếp theo, sau khi đã cấu hình và replicate qua Replica site. Nếu xảy ra sự cố bên Primary site, làm thế nào chúng ta enable các máy ảo bên Replicate Site (thuật ngữ enable máy ảo bên Replicate Site gọi là “Failover”) . Có 3 loại như sau :
Cho phép bạn test thử máy ảo bên Replica Site (còn máy ảo đang chạy thực sự là bên Primary Site) xem có bị lỗi hay trục trặc gì không. Khi chọn vào Test Failover như hình dưới, lúc này hệ thống sẽ yêu cầu bạn chọn thời điểm snapshot bạn muốn, sau đó nó sẽ sinh ra một máy ảo có tên “Name – Test Failover”. Và bạn có thể Start lên chạy thử.
Planned Failover phải cấu hình bằng tay, thực hiện trên Primary Site chỉ khi người quản trị muốn bảo trì (maintance) trên Primary Site và bắt buộc phải cho các máy ảo bên Replica Site phục vụ người dùng. Sau khi bảo trì xong thì enable lại Primary Site phục vụ người dùng.
Unplanned Failover chỉ thực hiện khi Primary Site chết đột ngột, lúc này bạn phải qua Hyper-V Server bên Replica Site để thực hiện Unplanned Failover, phục vụ cho người dùng. |