Tài liệu .Thiết lập SQL Server luôn sẵn sàng doc

Khi có thay đổi hoặc cập nhật từ CSDL chính, file log ghi lại các thay đổi này sẽ được gửi sang cho instance của máy chủ mirror.. Replication Nếu như Failover cluster và Log Shipping là

Thiết lập SQL Server luôn sẵn sàng

Giải pháp Database Mirroring giúp xây dựng hệ quản trị cơ sở dữ liệu (CSDL) có độ sẵn sàng cao trong SQL Server khá đơn giản và phù hợp với các CSDL loại vừa trở xuống

Yêu cầu về một hệ quản trị cơ sở dữ liệu có độ sẵn sàng cao ngày càng trở nên cấp thiết, đôi khi

là yếu tố sống còn với các tổ chức, công ty Tuy nhiên, để đạt mức độ sẵn sàng cao (gần như luôn hoạt động) là một điều không đơn giản, vì luôn có nhiều yếu tố làm ảnh hưởng đến hoạt động của hệ thống: sự cố phần cứng, hạ tầng mạng, lỗi hệ điều hành, lỗi phần mềm ứng dụng, virus… Bài viết giới thiệu về 1 giải pháp giúp đạt độ sẵn sàng cao (HA - High Availability) trên

hệ quản trị CSDL được dùng phổ biến hiện nay: SQL Server

Các giải pháp HA trên SQL Server

Failover cluster

Giải pháp này sử dụng một ổ cứng dùng chung – thường là SAN để chứa CSDL Có nhiều

“instance” của SQL Server được cài đặt, mỗi instance là 1 node, nhưng tại 1 thời điểm chỉ có 1

node được quyền điều khiển CSDL Khi node này gặp trục trặc, 1 node khác sẽ thay thế nó quản

lý CSDL

Log shipping

Cơ cấu bổ sung 1 CSDL làm mirror (bản sao) Khi có thay đổi hoặc cập nhật từ CSDL chính, file log ghi lại các thay đổi này sẽ được gửi sang cho instance của máy chủ mirror Bằng cách này,

người ta duy trì một bản sao cập nhật của CSDL Trong trường hợp xảy ra sự cố, CSDL bản sao

sẽ được chuyển thành CSDL chính trong thời gian ngắn

Replication

Nếu như Failover cluster và Log Shipping là 2 giải pháp đảm bảo high-availability ở cấp độ CSDL thì Replication chỉ đảm bảo high-availability ở cấp độ các đối tượng trong CSDL như

table, view… Các đối tượng này sẽ được copy sang một instance thứ 2 của SQL Server để lưu trữ

Data Mirroring trong SQL Server

Database Mirroring (DM) là giải pháp mới xây dựng CSDL có tính sẵn sàng cao trong SQL

Server DM khắc phục các nhược điểm của các giải pháp trước đó như:

• So với Failover Cluster, DM không yêu cầu phần cứng đặc biệt như SAN, vì vậy giảm được

chi phí khi cấu hình

• So với Log Shipping, DM có thể tự động chuyển sang máy mirror khi xảy ra lỗi mà không cần

người quản trị phải tác động Log shipping yêu cầu phải cấu hình thủ công bằng T-SQL Chính

vì vậy, DM được gọi là “hot standby”, khi thời gian gián đoạn (downtime) có thể tính bằng giây, còn Log-shipping được gọi là “warm standby”, vì thời gian gián đoạn có thể tính bằng phút hoặc hơn

• So với Replication, DM vượt trội hơn do bảo vệ được toàn bộ CSDL, còn Replication chỉ bảo

vệ từng phần trong CSDL, ví dụ các table như master

Tuy nhiên, DM chỉ có trong phiên bản Enterprise/Developer của SQL Server 2005 SP1/2008

1 Cơ cấu của DM trong SQL Server

DM trong SQL Server yêu cầu 3 instance: 1 instance chính (principal role) quản lý CSDL, 1

instance phụ (mirror) đảm bảo việc sao lưu CSDL 1 instance giám sát (witness) kết nối với 2 instance chính và phụ để giám sát và đảm bảo tính sẵn sàng của CSDL

Khi có mặt witness: Máy chủ witness kết nối với cả 2 máy chủ chính và máy chủ mirror Lúc này

toàn bộ hệ thống trở thành 1 quorum mà 2 trong số 3 thành phần có quyền quyết định Trong trường hợp máy chủ chính gặp sự cố, máy chủ witness sẽ tự động chuyển máy chủ mirror thành máy chủ chính Nếu sau đó, máy chủ chính hoạt động trở lại, máy chủ chính sẽ đảm nhận vai trò

là máy chủ mirror (2 máy chủ giờ đổi vai trò cho nhau) cho đến khi có sự can thiệp của nhà quản

trị (sơ đồ 1)

Khi không có máy chủ witness: Quá trình chuyển đổi tự động sẽ không thực hiện được mà cần có

tác động của nhà quản trị

Trong SQL Server có khái niệm “endPoint” có thể hiểu là “điểm kết nối”, cho phép các instance

SQL Server liên lạc với nhau thông qua giao thức TCP (sơ đồ 2)

Mỗi endpoint được xác định bằng một địa chỉ và cổng tương ứng Về mặt lý thuyết, địa chỉ phải

là địa chỉ tên miền đầy đủ, nhưng thực tế có thể dùng một trong 4 cách sau:

- Xác định thông qua tên server Ví dụ: TCP://PRINCIPAL:7024

- Xác định thông qua domain name Ví dụ: TCP://PRINCIPAL.DELTAX.COM:7024

- Xác định thông qua Ipv4 Ví dụ: TCP://192.168.1.3:7024

- Xác định thông qua Ipv6

Cần chú ý: Trong trường hợp các Instance SQL Server cùng chạy trên một máy thì cổng TCP

phải khác nhau

2 Trao đổi thông tin giữa máy chủ chính và máy chủ phụ

Chế độ tốc độ cao (High-Performance):

Chế độ High-Performance tương ứng với việc tạo bản sao không đồng bộ Máy chủ chính gửi các bản cập nhật sang máy chủ mirror và tiếp tục thực hiện các thay đổi khác mà không cần máy chủ mirror báo đã cập nhật thành công

Nhờ việc không phải chờ đợi máy chủ mirror cập nhật các thay đổi, nên máy chủ chính có tốc độ truy xuất nhanh hơn và tránh được tải không cần thiết

Quy trình này có thể được minh họa bằng lược đồ sau:

Đối với chế độ tốc độ cao, máy chủ mirror luôn cập nhật chậm hơn so với máy chủ chính, và có thể xảy ra mất mát dữ liệu trong trường hợp máy chủ chính gián đoạn hoạt động mà chưa kịp gửi

dữ liệu sang máy chủ mirror Tuy nhiên, phần CSDL khác biệt này tương đối nhỏ và có thể chấp nhận được Chế độ tốc độ cao – High performance mode không bắt buộc phải có máy chủ

Witness

Chế độ an toàn cao (High-Safety):

Khác với chế độ tốc độ cao, chế độ an toàn cao sử dụng cơ chế đồng bộ (Synchronous) Khi ứng dụng hoặc người dùng cập nhật, nó sẽ được cập nhật gần như đồng thời trên cả máy chủ chính và máy chủ mirror Điều này sẽ đảm bảo khi máy chủ chính xảy ra sự cố, máy chủ mirror sẽ có bản sao đầy đủ và toàn vẹn của CSDL, vì vậy đảm bảo an toàn dữ liệu cao

Chế độ an toàn cao yêu cầu một máy chủ witness để đảm bảo tính thay thế nóng - hot standby

3 Cấu hình DM:

Cấu hình DM trên SQL Server gồm 3 bước cơ bản:

- Sao lưu (backup) toàn bộ CSDL trên máy chủ chính và sau đó khôi phục (restore) trên máy chủ mirror

- Tạo các endpoint tương ứng để các máy chủ chính, mirror và witness làm việc với nhau

- Tạo một phiên làm việc (Database Mirroring Session)

Việc cấu hình DM có thể thực hiện bằng giao diện của SQL Server Management Studio (SSMS), hoặc có thể cấu hình bằng T-SQL

Cấu hình bằng giao diện của SQL Server Management Studio khá đơn giản, sau khi đã restore

dữ liệu thành công trên máy chủ mirror, chỉ cần nhấn chuột phải vào cơ sở dữ liệu và chọn

“Mirroring”, sau đó thực hiện theo từng bước

Kết quả thu được sẽ là việc khởi tạo một session của DM

Việc cấu hình bằng SSMS cho phép loại bỏ gần hết các thao tác khi thực hiện bằng T-SQL, tuy nhiên nếu muốn bạn vẫn có thể dùng T-SQL để đạt độ mềm dẻo cao nhất

Cấu hình trên T-SQL có thể dùng 2 cách để các endpoint xác thực lẫn nhau: Xác thực bằng login hoặc xác thực bằng certificate Đoạn mã T-SQL hoàn thiện để cấu hình DM khá dài nên chúng tôi chỉ giới thiệu một số bước tiêu biểu

Cấu hình bằng Login

Giả sử chúng ta dùng tài khoản Windows để đăng nhập vào SQL Server, trường hợp dùng tài khoản SQL Server cũng thực hiện hoàn toàn tương tự

CREATE LOGIN [PRICIPAL-SRV\Administrator]

FROM WINDOWS

GO

Tạo các endpoint:

CREATE ENDPOINT Partner

STATE = STARTED

AS TCP ( LISTENER_PORT = 5022 )

FOR DATABASE_MIRRORING (

AUTHENTICATION = WINDOWS NEGOTIATE,

ENCRYPTION = SUPPORTED,

ROLE=ALL)

GO

Chú ý là việc tạo endpoint với ROLE=ALL cần thực hiện trên cả máy chủ principal và mirror, trên máy chủ witness, bạn thay bằng ROLE=WITNESS

Cấu hình bằng Certificate:

Thay vì sử dụng tài khoản login để cho các endpoint nhận diện nhau, có thể dùng giải pháp thay thế là tạo các chứng thực – certificate

- Tạo mã hóa master key (bắt buộc để xuất certificate):

create master key encryption by password = 'abc123!!';

- Tạo một cerfiticate:

create certificate PRINCIPAL_cert

with subject = 'PRINCIPAL certificate',

start_date = '2007/11/01',

expiry_date = '2020/11/01';

- Tạo endpoint tương ứng với certificate:

Create endpoint endpoint_mirroring state = started

as tcp(listener_port = 7024, listener_ip = all) for database_mirroring (authentication = certificate PRINCIPAL_cert, encryption = disabled, role = all);

- Xuất certificate ra một file riêng:

Backup certificate PRINCIPAL_cert to file = 'c:\PRINCIPAL_cert.cer';

Thực hiện tương tự trên máy chủ mirror và witness, chú ý thay đổi role = witness khi cần thiết

Sau khi đã tạo các Endpoint và xuất các certificate trên cả 3 instance, quay trở lại máy chủ principal:

- Tạo một login cho máy chủ mirror:

create login MIRROR_login with PASSWORD = 'abc123!!';

GO

- Tạo một user tương ứng với Login đó

create user MIRROR_user from login MIRROR_login;

GO

- Tạo certificate từ file cer của máy chủ mirror:

Create certificate MIRROR_cert

Authorization MIRROR_user

From file = 'c:\MIRROR_cert.cer';

GO

- Cấp quyền kết nối đến endpoint cho login của máy chủ mirror:

Grant CONNECT ON Endpoint::endpoint_mirroring to [MIRROR_login];

GO

Thực hiện công việc tương tự đối với

certificate của máy chủ witness, cũng

như trên các máy chủ mirror và witness

để 3 máy có thể nhận diện và xác thực

lẫn nhau

Sau khi đã tạo các endpoint, bạn có thể

kiểm tra chúng bằng truy vấn:

SELECT name, state_desc, role_desc

FROM sys.database_mirroring_endpoint

Công việc cuối cùng là khởi tạo một session cho DM:

* Trên máy chủ principal:

ALTER DATABASE AdventureWorks

SET PARTNER = 'TCP://mirror-srv.deltax.com:5022' GO

* Trên máy chủ mirror:

ALTER DATABASE AdventureWorks

SET PARTNER = 'TCP://pricipal-srv.deltax.com:5022' GO

* Trên máy chủ principal, thiết lập máy chủ witness:

ALTER DATABASE AdventureWorks

SET WITNESS = 'TCP://witness-srv.deltax.com:5022'

GO

Sau khi hệ thống đã đi vào hoạt động, có thể giám sát bằng công cụ Database Mirroring Monitor:

4 Lập trình middleware:

Việc sử dụng DM có thể nói là gần như trong suốt đối với việc kết nối CSDL từ phía

middleware Nếu bạn sử dụng thư viện ADO.NET, chỉ cần sửa đổi ConnectionString để thêm trường “failover partner” chỉ đến máy chủ mirror, ví dụ:

Data Source=pricipal.database.com;Failover Partner=mirror.database.com;Initial

Catalog=AdventureWorks;

Integrated Security=True;

Ngoài ra, ADO.NET tạo một “connection pool” cho phép lưu đệm (cache) các connection đã

được khởi tạo, nên trong trường hợp xảy ra sự cố dẫn đến phải chuyển đổi máy chủ, bạn cần chủ động thực hiện thêm thao tác xóa bộ nhớ cache này

SqlConnection.ClearPool(conn);

Lời kết

DM trong SQL Server khá đơn giản, dễ cấu hình, sử dụng và theo dõi, tuy nhiên khả năng của nó tương đối hạn chế Nó chỉ phù hợp với các CSDL loại vừa trở xuống, còn với các CSDL lớn có yêu cầu nghiêm ngặt về tính liên tục thì cách làm

đề xuất ở trên chưa đáp ứng được mà cần những giải pháp tổng thể cả về hệ điều hành, hệ thống phần cứng, mạng

Bài viết hy vọng giúp bạn có cái nhìn tổng quan về giải pháp xây dựng hệ quản trị CSDL có độ sẵn sàng cao trong SQL Server

Tham khảo: http://technet.microsoft.com/en-us/library/cc917680.aspx

Chúc các bạn thành công