Giải pháp always on trong sql server 2012

1. Giải pháp AlwaysOn trong SQL Server
2012
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

2. đâ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

3. 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

4. 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

5. 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

6. 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

7. đ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.

8. 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

9. 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.

10. Đ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.

11. 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

12. Đặ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.

13. 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

14. 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;

15. 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

16. 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

17. 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.

18. 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