Giải pháp AlwaysOn trong SQL Server2012

Giải pháp AlwaysOn trong SQL Server 2012Reviewed by Google

on Jun 11Rating: 5.0

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 FCIReplicas within an

availability group

Uses WSFC cluster Yes Yes

Protection level Instance Database

Storage type Shared Non-shared

Storage solutionsDirect attached, SAN,

mount points, SMB

Depends on node

type

Readable

secondariesNo Yes

Applicable failover

policy settings

WSFC quorum

FCI-specific

Availability group

settings

WSFC quorum

Availability group

settings

Failed-over

resources

Server, instance, and

databaseDatabase 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