Giải pháp AlwaysOn trong SQL Server 2012

AlwaysOn là 1 giải pháp toàn diện, đơn giản và linh hoạt đảm bảo tính sẵn sàng cao của hệ thống (High Availability) và khả năng phục hồi dữ liệu sau thảm họa (Disaster Recovery) mới được cung cấp trong SQL Server 2012.

SQL Server AlwaysOn hoạt động dựa trên nền tảng Windows Server Failover Clustering (WSFC) để có thể tăng cường tính sẵn sàng của ứng dụng, tiết kiệm chi phí và tận dụng phần cứng tốt hơn.

SQL Server AlwaysOn cung cấp khả năng về HA & DR ở 2 level:

• Database: thông qua tính năng AlwaysOn Availability Group (AG)
• Instance: sử dụng AlwaysOn Failover Cluster Instance (FCI)

Thông thường, chúng ta nên sử dụng AlwaysOn Availability Group để bảo vệ dữ liệu trong SQL Server nhưng nếu như có sử dụng giải pháp shared disk của third-party (ví dụ như SAN) thì AlwaysOn Failover Cluster Instance là lựa chọn hợp lý hơn.

Đây là những giải pháp có thể thay thế cho giải pháp Database Mirroring và Log Shipping trong những phiên bản SQL Server trước đây, với 1 số ưu điểm như:

• Hỗ trợ đầy đủ tính năng ảo hóa
• Không cần phải sử dụng shared storage nên không sợ bị single-point-of-failure
• Hỗ trợ sẵn replication
• Quản lý dễ dàng và hiệu quả với giao diện đồ họa UI trực quan và thông qua việc tích hợp trong System Center Operation Manager (SCOM)

Dựa vào 2 level trên, những người quản trị có thể xây dựng những mô hình khác nhau để đảm bảo tính sẵn sàng cao (HA) cũng như khả năng phục hồi dữ liệu sau thảm họa (DR) cho hệ thống cơ sở dữ liệu của mình:

1. Sử dụng AG cho cả HA & DR

2. Sử dụng Multi-site FCI cho cả HA & DR

3. Sử dụng FCI cho local HA và AG cho DR

A. ALWAYSON AVAILABILITY GROUPS:

Tính năng AlwaysOn Availability Groups là 1 giải pháp HA & DR thay thế cho tính năng Database Mirroring hoặc Log Shipping.

Mỗi một Availability Group hỗ trợ môi trường failover cho 1 nhóm các user database nhất định, gọi là Availability Databases. Nhóm các database này sẽ cùng ở chung trong 1 Instance, được gọi là Replica. Các databases trong 1 group có khả năng fail over cùng nhau từ 1 Replica chính (primary replica), trong những trường hợp cần thiết, qua 1 Replica khác (secondary replica). Luôn có 1 primary replica duy nhất và có thể có tối đa 4 secondary replica, trong đó tối đa 2 active secondary replica cho phép đọc và/hoặc thực hiện backup. Mỗi replica phải ở trên các node khác nhau trong 1 WSFC cluster, nghĩa là mỗi Instance phải ở trên 1 server khác nhau (có thể là 1 server vật lý hay 1 server ảo)

Một availability group chỉ có thể fail over ở level replica (instance). Việc fail over sẽ không diễn ra ở level của database bởi các vấn đề như mất data files, database bị xóa hay transaction log bị hỏng.

Các ứng dụng (Application) kết nối đến các database nằm trong 1 availability group thông qua các Availability Group Listeners. Listener đóng vai trò như 1 gateway (hay server ảo) để cung cấp khả năng chuyển hướng các client connection đến primary replica.

Các Chế độ Đồng bộ

AlwaysOn Availablity Groups hỗ trợ 2 chế độ đồng bộ giữa primary replica và một secondary replica:

• Asynchronous-commit mode: thay thế cho Log Shipping để xây dựng một giải pháp DR cho những Replica ở cách xa nhau về mặt địa lý.

  Trong chế độ này, các transaction log của primary replica sẽ được gửi 1 cách không liên tục và không đồng bộ để commit ở secondary replica. Vì thế không bắt buộc dữ liệu trong các replica là phải giống nhau mà có thể chấp nhận 1 độ trễ nhất định để đồng bộ dữ liệu giữa các replica.

  Asynchronous-commit mode không hỗ trợ Automatic Failover. Trong những trường hợp gặp xử cố, người quản trị phải tự mình fail over database (force manual failover) để chuyển 1 secondary replica thành primary replica, và chấp nhận việc mất dữ liệu.

• Synchronous-commit mode: thay thế cho Database Mirroring để có thể đảm bảo toàn vẹn dữ liệu ở tối đa 3 Replica (kể cả primary replica)

  Chế độ này yêu cầu primary replica chỉ được commit transaction log sau khi transaction log đã được gửi đến và commit ở secondary replica. Tốc độ đồng bộ sẽ bị giảm đáng kể nếu như đường truyền không tốt nhưng bù lại dữ liệu được bảo toàn, tránh bị mất dữ liệu nếu gặp sự cố.

  Synchronous-commit mode hỗ trợ cả Automatic Failover và Planned Manual Failover, đảm bảo dữ liệu được bảo toàn sau khi fail over.

  AlwaysOn Availability Groups hỗ trợ tối đa 2 secondary replica có thể cấu hình synchronous-commit mode với primary replica.

Các Chế độ Failover

Failover cung cấp khả năng để các replica có thể tráo đổi vai trò của nhau trong những trường hợp cần thiết. Có 3 chế độ Failover được hỗ trợ:

• Force Manual Failover (Force Failover): (mất dữ liệu) chỉ xảy ra khi cấu hình ở chế độ đồng bộ asynchronous-commit mode. Force failover là 1 lựa chọn khôi phục dữ liệu sau thảm họa (DR) trong những trường hợp secondary replica không thể đồng bộ với primary replica và khi đó phải chấp nhận mất dữ liệu.
• Planned Manual Failover (Manual Failover): (không mất dữ liệu) người quản trị sẽ quyết định failover 1 secondary replica thành primary replica vì 1 mục đích nào đó ví dụ như bảo trì/ nâng cấp/ thay thế primary replica hiện hành. Manual failover chỉ xảy ra khi secondary được cấu hình synchronous-commit mode và đã được đồng bộ (synchronized) với primary replica.
• Automatic Failover: (không mất dữ liệu) quá trình failover sẽ tự động xảy ra giữa 1 synchronized secondary replica và primary khi các thỏa mãn các điều kiện sau:
  • Chế độ đồng bộ giữa secondary replica và primary replica là synchronous-commit mode.
  • Cả 2 replica đều chọn chế độ failover là Automatic Failover.
  • Ngay trước khi failover, trạng thái của secondary replica là synchronized.
  • Trong WSFC phải có Quorum và thỏa mãn failover policy

Trong các điều kiện trên, Flexibile failover policy là 1 trong những điều kiện quan trọng quy định những nguyên nhân/ điều kiện để automatic failover xảy ra, bao gồm 2 yếu tố:

• Health-check timeout Threshold: sử dụng sp_server_diagnostics để kiểm tra sức khỏe của primary replica. Thời gian phản hồi được chấp nhận mặc định là 30 giây, nếu lâu hơn đồng nghĩa với việc primary replica có vấn đề.

Failure-condition level: có 5 level quy định giới hạn cho những điều kiện có thể dẫn đến quá trình failover. Level 2 là mặc định. Xem chi tiết: Flexible Failover Policy for Automatic Failover of an Availability Group.

1. Cấu hình Windows Server Failover Cluster

Để cấu hình WSFC, các bước thực hiện như sau:

1.1. Cài đặt tính năng Failover Clustering cho từng Server tham gia với vai trò là một Node trong Cluster.

• Mở Server Manager, vào mục Features.
• Click Add Features
• Trong Select Features page, chọn install feature Failover Clustering.

1.2 Tạo 1 Cluster có 2 Node

Bước này chỉ cần thực hiện trên 1 trong những Server đã cài đặt Failover Cluster feature và sẽ được cấu hình thành Node trong Cluster.

• Mở Failover Cluster Management.
• Trong mục Management, chọn Create a Cluster.
• Add 2 server, sử dụng FQDN để chỉ ra tên Server.

• Click Next để qua trang cấu hình Access Point for Administering the Cluster.
• Điền Name và IP cho Cluster. Thông thường IP này sẽ thuộc subnet là interface giao tiếp với bên ngoài cluster.
• Click Finish để tạo 1 cluster đã được cấu hình với 2 node ở trên.

1.3 Cấu hình Quorum (nếu muốn có Automatic Failover)

Chế độ Automatic Failover đòi hỏi Cluster phải được cấu hình Quorum mode. Có 4 quorum mode trong WSFC. Availability Groups hỗ 2 mode trong số 5 mode đó:

• Node and File Share Majority trong trường hợp số node là chẵn
• Node Majority trong trường hợp số node là lẻ

Trong trường hợp này (số node chẵn =2), các bước thực hiện như sau:

• Trong Failover Cluster Management, right click Cluster vừa được tạo và chọn More Actions –> Configure Cluster Quorum Settings.
• Trong trang Select Quorum Configuration, chọn Node and File Share Majority.

• Điền UNC path của 1 shared folder trong mục Shared Folder Path.

2. Bật tính năng AlwaysOn Availability Groups

Thực hiện đối với từng Server (hay Instance) như sau:

• Mở SQL Server Configuration Manager, chọn SQL Server Services
• Chọn Properties của service thực thi cho Instance (Database engine) chứa các database cần có.
• Vào tab AlwaysOn High Availability, tích chọn Enable AlwaysOn Availability Groups.
• Restart lại service.

Với các phiên bản thử nghiệm (TCP hay RC), chúng ta phải enable lại
tính năng này mỗi khi service bị restart hoặc phải add vào Startup
Parameters tham số -T9532.

3. Thiết lập Availability Groups

Các bước để thiết lập Availability Groups cho 1 nhóm các database sẽ như sau (không thể áp dụng cho
các system databases):

• Vào SQL Server Management Studio (SSMS), connect đến Instance sẽ được cấu hình thành Primary Replica.
• Mở folder Management trong Object Explorer
• Right Click Availability Groups, chọn New Availability Group Wizard

• Đặt tên cho Availability Group, ví dụ: DemoAG.
• Add 1 hoặc nhiều database.

Chỉ có thể chọn các Database thỏa mãn các yêu cầu sau:
– Phải là read-write user database
– Đang thiết lập multi-user và không sử dụng AUTO_CLOSE
– Đang được thiết lập ở chế độ Full Recovery mode
– Đã có có 1 bản Full Backup
– Không tham gia vào trong bất kì 1 Availability Group hay
Database Mirroring nào khác

Chỉ định Secondary Replica và Replica Mode: là tổ hợp gồm Automatic Failover mode và Synchronous-commit mode.

Chọn Readable Secondary mode: Yes, No, hoặc Read-intent only.

Read-intent only là 1 lựa chọn mới chỉ cho phép Application access xuống database để đọc trong trường hợp có khai báo trong Connection String tham số “Application Intent=readonly”.

• Chọn Perform Initial Data Synchronization và chỉ định shared folder (theo UNC path) nếu muốn khởi tạo dữ liệu đồng bộ.
• Finish và review kết quả

4. Tạo Availability Group Listener

Để 1 Application luôn kết nối đến Primary replica để đọc/ghi dữ liệu trên các database của Availability Group, chúng ta phải tạo 1 Listener cho Availability Group đó. Các bước thực hiện như sau:

• Mở Availability Group vừa tạo, right click Availability Group Listeners.
• Chọn Add Listener.
• Điền tên của Listener DNS Name, ví dụ: DemoAG_Listener
• Chọn port và IP cho Listener, ví dụ: port 1433 và IP là 192.168.1.99

5. Chỉnh Connection string của Application

Sau khi đã cấu hình Availability Group và tạo Listener, các Application có thể connect đến các database thông qua Listener thay vì chỉ định 1 server cụ thể nào đó như trước đây.

Ví dụ sau đây khai báo 1 connection string chỉ đến 1 Listener:

Provider=SQLNCLI11.1;
Data Source=DemoAG_Listener;
Integrated Security=SSPI;
Initial Catalog=Adventureworks;
Timeout=1;

Trong trường hợp Replica mode của Secondary replica là Read-intent only, để Application connect thẳng vào Secondary replica này để đọc dữ liệu chúng ta có thể khai báo connection string như sau:

Provider=SQLNCLI11.1;
Data Source=SQLDENALI02;
Integrated Security=SSPI;
Initial Catalog=Adventureworks;
Timeout=1;
Application Intent=Readonly;

B. ALWAYSON FAILOVER CLUSTER INSTANCE:

AlwaysOn FCI cho phép chúng ta thiết lập fail over ở tầng Instance cùng với 1 WSFC Cluster. Khi đó 1 Availability Replica có thể nằm trên 1 Standalone Instance hoặc là 1 FCI Instance.

Nếu như AlwaysOn Availability Groups không phụ thuộc vào shared storage thì ngược lại, nếu như chúng ta sử dụng SQL Server FCI để chứa 1 hay nhiều Availability Replicas, mỗi một FCI được cấu hình phải có chung 1 shared storage.

Một FCI sẽ chạy dựa trên 1 WSFC Resource group, bao gồm 1 hay nhiều WSFC node. Khi start up FCI, 1 trong những node trên sẽ chiếm được quyền kiểm soát (take ownership) toàn bộ resource trong Resource group đó, bao gồm: Network name, IP, shared disks, SQL Server services (Database engine, Agent, Analysis Services, …).

1. Các Yếu tố Cấu thành Trong FCI

Một FCI bao gồm 1 tập các physical server (node) có cấu hình phần cứng cũng như phần mềm (OS, SQL Version, Instance name,…) tương tự nhau. Đây là yêu cầu tiên quyết để FCi có thể fail over giữa các node với nhau.

WSFC Resource Group

Một SQL server FCI chạy trên 1 WSFC resource group. Mỗi node trong resource group này duy trì 1 bản sao được đồng bộ với nhau, và tại 1 thời điểm chỉ có duy nhất 1 node sử dụng được resource group đó, gọi là active node. WSFC quản lý tất cả cấu hình, bao gồm: cấu hình quorum, failover policy, failover oprerations, VNN hay virtual IP của FCI. Trong trường hợp có lỗi xảy ra, việc sử dụng resource group sẽ được chuyển cho 1 node khác trong FCI. Số lượng các node hỗ trợ trong 1 WSFC resoure group phụ thuộc vào bản edition SQL Server đang cài đặt.

Trong cùng 1 WSFC cluster, có thể có nhiều FCI (multiple resource group), phụ thuộc vào khả năng của phần cứng như CPU, memory, disk,…

SQL Server Binaries

Các binary files sẽ được cài đặt trên từng node của FCI như việc cài đặt dạng stand-alone thông thường. Tuy nhiên, các SQL Server service sẽ không chạy automatic mà được quản lý bởi WSFC.

Storage

Khác với AlwaysOn Availability Group, 1 FCI phải sử dụng shared storage giữa các node để lưu trữ database và log. Shared storage này có thể là WSFC cluster disk, disk trong SAN, hay 1 file shares trong SMB. Điều này đồng nghĩa với việc storage chính là 1 trong những điểm yếu nhất, là gót chân asin, trong giải pháp FCI.

Network Name

Virtual Network Name (VNN) cung cấp 1 điểm kết nối đồng nhất cho FCI. VNN cho phép ứng dụng connect đến các database thông qua VNN mà không cần biết Active node hiện thời. Trong trường hợp failover xảy ra, quá trình chuyển đổi Active node là trong suốt đối với ứng dụng và thời gian downtime được giảm tối đa.

Virtual IPs

Trong trường hợp sử dụng multi-subnet FCI, 1 virtual IP sẽ được gán cho mỗi subnet trong FCI đó. Khi xảy ra failover, VNN trong DNS sẽ được cập nhật lại đến 1 virtual IP mới. Như vậy, application hay client vẫn kết nối tới FCI thông qua cùng 1 VNN mà không cần biết đang kết nối tới subnet nào.

2. Ưu Điểm

• Bảo vệ dữ liệu ở tầng Instance.
• Khả năng Automatic Failover trong trường hợp bị lỗi hardware, OS, service hay application).
• Hỗ trợ nhiều giải pháp lưu trữ khác nhau, bao gồm WSFC cluster disk như iSCSI, Fiber Channel, …
• Có thể áp dụng giải pháp khôi phục dữ liệu sau thảm họa bằng việc sử dụng multi-subnet FCI hoặc 1 FCI để chứa các database trong 1 AlwaysOn availability group mà không cần phải cấu hình virtual LAN.
• Không cần phải cấu hình lại application hay client sau khi fail over xảy ra.

3. FCI vs. Availability Groups

Bất kể số lượng các node có trong 1 FCI, 1 FCI chỉ có thể chứa 1 replica duy nhất cho 1 Availability Group. Bảng dưới đây liệt kê điểm khác nhau giữa các node trong 1 FCI và các replica trong 1 Availability Group.

	Nodes within an FCI	Replicas within an availability group
Uses WSFC cluster	Yes	Yes
Protection level	Instance	Database
Storage type	Shared	Non-shared
Storage solutions	Direct attached, SAN, mount points, SMB	Depends on node type
Readable secondaries	No	Yes
Applicable failover policy settings	WSFC quorum FCI-specific Availability group settings	WSFC quorum Availability group settings
Failed-over resources	Server, instance, and database	Database only

Nguồn: q u a n g n h a t 1 4 0 1 . w o r d p r e s s . c o m