Mô hình dịch vụ trên mạng hướng đến tính sẵn sàng dịch vụ áp dụng cho hệ thống dịch vụ tại Công ty Viễn thông Viettel

Mô hình dịch vụ trên mạng hướng đến tính sẵn sàng dịch vụ áp dụng cho hệ thống dịch vụ tại Công ty Viễn thông Viettel Mô hình dịch vụ trên mạng hướng đến tính sẵn sàng dịch vụ áp dụng cho hệ thống dịch vụ tại Công ty Viễn thông Viettel luận văn tốt nghiệp thạc sĩ

Nguyễn Thành Dương

MÔ HÌNH DỊCH VỤ TRÊN MẠNG HƯỚNG ĐẾN TÍNH SẴN SÀNG DỊCH VỤ - ÁP DỤNG CHO HỆ THỐNG

DỊCH VỤ TẠI CÔNG TY VIỄN THÔNG VIETTEL

Chuyên ngành : Kỹ thuật máy tính và truyền thông

LUẬN VĂN THẠC SĨ KỸ THUẬT

KỸ THUẬT MÁY TÍNH VÀ TRUYỀN THÔNG

NGƯỜI HƯỚNG DẪN KHOA HỌC :

TS PHẠM HUY HOÀNG

LỜI CAM ĐOAN

Tôi xin cam đoan đề tài nghiên cứu của tôi hoàn toàn do tôi tự làm dưới sự hướng dẫn của TS Phạm Huy Hoàng Những kết quả nghiên cứu, thử nghiệm được thực hiện tại trung tâm công nghệ thông tin – Công ty Viettel Telecom Các

số liệu kết quả trình bày trong luận văn là hoàn toàn trung thực và chưa từng được công bố trong bất cứ công trình nào

Các tài liệu tham khảo sử dụng trong luận văn đều được dẫn nguồn (có bảng thống kê các tài liệu tham khảo) hoặc được sự đồng ý trực tiếp của tác giả

Nếu xảy ra bất cứ điều gì không đúng như lời cam đoan trên, tôi xin chịu hoàn toàn trách nhiệm trước Viện và Nhà trường

Hà Nội, ngày tháng năm 2013

Tác giả

Nguyễn Thành Dương

mà còn là hành trang quý báu để tôi bước vào đời một cách vững chắc và tự tin

Tôi cũng thầm biết ơn sự ủng hộ của Ban Giám đốc trung tâm công nghệ thông tin – Công ty viễn thông Viettel, đồng nghiệp, gia đình và bạn bè – những người thân yêu luôn là chỗ dựa vững chắc cho tôi

Cuối cùng, tôi xin kính chúc Quý Thầy cô, Đồng nghiệp, Gia đình dồi dào sức khỏe và thành công trong sự nghiệp cao quý

Xin trân trọng cảm ơn!

Học viên

Nguyễn Thành Dương

MỤC LỤC

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

DANH SÁCH THUẬT NGỮ VÀ VIẾT TẮT 5

DANH MỤC BẢNG - HÌNH VẼ 7

LỜI NÓI ĐẦU 9

TỔNG QUAN VỀ NHIỆM VỤ CỦA LUẬN VĂN 10

PHẦN A: TỔNG QUAN VỀ TÍNH SẴN SÀNG CỦA HỆ THỐNG 11

1 Khái niệm về tính sẵn sàng 11

1.1 Tính sẵn sàng hệ thống 11

1.2 Thời gian downtime có tính toán và không có tính toán 12

1.3 Tính toán độ sẵn sàng 13

1.4 Phép đo và sự lý giải 14

1.5 Các nhân tố gây ra tính không sẵn sàng của hệ thống 14

1.6 Các khái niệm liên quan 15

2 Phân loại 15

3.1 Sẵn sàng về ứng dụng 16

2.2 Sẵn sàng về thiết bị phần cứng 16

2.3 Sẵn sàng về dữ liệu 17

2.4 Sẵn sàng về đường truyền mạng 22

3 Một số mô hình hệ thống hướng đến tính sẵn sàng 22

3.1 Thiết kế hệ thống có tính sẵn sàng cao 22

3.2 Mô hình failover cơ bản 24

3.3 Cấu hình failover nâng cao 27

3.4 Mô hình cluster và bộ lưu trữ 30

PHẦN B: NÂNG CAOTÍNH SẴN SÀNG TRONG HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU 35

1 Tính sẵn sàng trong hệ quản trị cơ sở dữ liệu 35

2 Các kiến trúc nâng cao tính sẵn sàng của cơ sở dữ liệu oracle 36

2.1 Kiến trúc database đơn 37

2.2 Kiến trúc RAC 39

2.3 Kiến trúc dataguard 40

2.4 Kiến trúc có tính sẵn sàng cao nhất (MAA) 42

2.5 Streams 43

3 Backup và restore 44

4 Giám sát hệ thống 47

4.1 Giao thức 49

4.2 Truy cập dữ liệu 49

4.3 Chế độ 49

5 Một số công cụ giám sát oracle 51

5.1 Oracle Enterprise Manager 51

5.2 Một số công cụ giám sát của hãng thứ 3 53

PHẦN C: XÂY DỰNG HỆ THỐNG GIÁM SÁT CẢNH BÁO CSDL ORACLE TẠI VIETTEL 56

1 Hiện trạng hoạt động hệ thống dịch vụ 56

2 Bất cập trong vấn đề giám sát vận hành 57

3 Các công cụ monitor database thường được sử dụng 57

4 Xây dựng công cụ giám sát, cảnh báo riêng 59

4.1 Mô hình chung 59

4.2 Chương trình cảnh báo, giám sát 62

4.3 Tính tùy biến và mở rộng của hệ thống giám sát 67

5 Triển khai hệ thống giám sát cảnh bảo tại các hệ thống dịch vụ tại Công ty Viễn thông Viettel 68

KẾT LUẬN 70

TÀI LIỆU THAM KHẢO 71

DANH SÁCH THUẬT NGỮ VÀ VIẾT TẮT

HA High Availability

LCR Local Continuous Replication

CCR Cluster Continuous Replication

SCC Single Copy Clusters

SCR Standby Continuous Replication

CSDL Cơ Sở Dữ Liệu

SQL Structured Query Language

NLB Network Load Balance

IP Internet Protocol

TCP/IP Transmission Control Protocol / Internet Protocol

VCS Veritas Cluster Server

RAID Redundant Array of Independent Disk

LUN Logical Unit Number

CPU Central Processing Unit

MAA Maximum Availabity Architecture

RAC Real Application Cluster

PL/SQL Procedural Language extension of SQL

DDL Data Definition Language

LCR Logical Change Record

FC – SAN Fibre Channel – Storage Area Network

RPO Recovery Time Objective

RMAN Recovery Manager

SNMP Simple Network Management Protocol

MIB Management Information Base

UDP User Datagram Protocol

JMX Java Management Extensions

SSH Secure Shell

TELNET Telephone Network

OMA Oracle Management Agent

TOAD Tool for Oracle Application Developers

DANH MỤC BẢNG - HÌNH VẼ

Bảng 1: Tính sẵn sàng và thời gian downtime 14

Hình 1: Local Continuous Replication 17

Hình 2: Cluster Continuous Replication 18

Hình 3: Single Copy Cluster 19

Hình 4: StandbyContinuous Replication 19

Hình 5: Cấu hình bất đối xứng 25

Hình 6: Cấu hình đối xứng 25

Hình 7: Cấu hình N – 1 26

Hình 8: Cấu hình N – 1 khi có lỗi 27

Hình 9: Cấu hình N + 1 28

Hình 10: Cấu hình N + 1 khi có lỗi 29

Hình 11: Cấu hình N – N 29

Hình 12: Cụm lưu trữ chia sẻ cơ bản 30

Hình 13: Cụm lưu trữ chia sẻ lớn 31

Hình 14: Cụm lưu trữ không chia sẻ 32

Hình 15: Cụm dữ liệu đồng bộ 33

Hình 16: Global cluster 34

Hình 17: Các giải pháp cho kiến trúc CSDL 36

Hình 18: Kiến trúc RAC 40

Hình 19: Kiến trúc dataguard 42

Hình 20: Kiến trúc MAA 43

Hình 21: Kiến trúc stream 44

Hình 22: Giao diện oracle control homepage 52

Hình 23: Giao diện Toad 54

HÌnh 24: Giao diện manage Engine 55

Hình 25: Mô hình dịch vụ thực tế đang chạy 56

Hình 26: Giao diện giám sát Manage Engine 58

Hình 27: Mô hình giám sát chung 59

Bảng 2: Bảng tổng hợp backup log 65

Bảng 3: Bảng tổng hợp dataguard 67

Hình 28: Mô hình triển khai công cụ giám sát 69

LỜI NÓI ĐẦU

Xuất phát từ thực tế vận hành khai thác, một hệ thống được đưa vào hoạt động không thể tránh khỏi những lúc bị lỗi Thời điểm hệ thống bị lỗi, gây downtime lớn cho dịch vụ chủ yếu lại xảy ra khi người quản trị không trực tiếp vận hành, xử lý, hoặc đang ở xa mà không biết có sự cố đang xảy ra Đôi khi có những lỗi rất đơn giản nhưng nếu không được xử lý ngay sẽ làm sập hệ thống và ảnh hưởng đến chất lượng dịch vụ

Việc nâng cao tính sẵn sàng cho hệ thống là một mục tiêu đặt ra đối với bất

cứ doanh nghiệp kinh doanh nào Một trong các công việc đó là nâng cao khả năng giám sát, theo dõi hệ thống nắm bắt được những vấn đề đang diễn ra trong hệ thống

Trong luận văn này, tôi sẽ trình bày những vấn đề cơ bản của tính sẵn sàng của một hệ thống, cũng như việc nâng cao tính sẵn sàng của một cơ sở dữ liệu Từ

đó đưa ra giải pháp nâng cao tính sẵn sàng cho hệ thống áp dụng trong điều kiện thực tế

TỔNG QUAN VỀ NHIỆM VỤ CỦA LUẬN VĂN

Thị trường di động và thiết bị thông minh đang phát triển một cách mạnh

mẽ, các dịch vụ đi kèm ngày càng chứng tỏ vai trò quan trọng đem lại thu nhập không nhỏ đối với các nhà mạng Do vậy, hệ thống hoạt động ổn định đóng vai trò

to lớn trong việc nâng cao tính sẵn sàng của dịch vụ

Với sự phát triển rất nhanh của mạng internet, thì hầu hết các doanh nghiệp hiện nay đang muốn tự mình quản lý hạ tầng công nghệ thông tin của mình để chủ động triển khai các chương trình, những ứng dụng mang tính đột phá, đem lại hiệu quả bất ngờ cho doanh nghiệp Sự cạnh tranh, lợi nhuận và khách hàng, tất cả đều phụ thuộc vào sự ổn định của hệ thống

Có rất nhiều cách để nâng cao tính sẵn sàng của hệ thống Giải pháp của tôi

là tăng cường khả năng giám sát hệ thống Không có một công cụ giám sát nào hoàn hảo áp dụng cho tất cả các hệ thống, vì vậy, việc xây dựng một công cụ giám sát đặc thù phù hợp với doanh nghiệp là điều cần thiết

Luận văn được chia làm 3 phần với nội dung chính như sau:

Phần A: Cơ sở lý thuyết về tính sẵn sàng của hệ thống, các nguyên nhân dẫn tới sự bất ổn định trong hệ thống và một số phương pháp nâng cao tính sẵn sàng của hệ thống

Phần B: Cơ sở lý thuyết về việc nâng cao tính sẵn sàng của cơ sở dữ liệu, các mô hình kiến trúc của cơ sở dữ liệu oracle, các giải pháp như backup, restore

và giám sát hệ thống

Phần C: Xây dựng công cụ giám sát riêng, triển khai áp dụng tại môi trường thực tế đáp ứng yêu cầu công việc

PHẦN A: TỔNG QUAN VỀ TÍNH SẴN SÀNG CỦA

HỆ THỐNG

Hệ thống luôn luôn hoạt động là một ưu tiên hàng đầu cho nhiều hoạt động kinh doanh và cho các hệ thống máy chủ lớn Từ các doanh nghiệp nhỏ và vừa trong nước cũng như các doanh nghiệp nước ngoài, ngày càng có nhiều ngành đòi hỏi các công ty cung cấp dịch vụ chú trọng đến dịch vụ khách hàng và cung cấp hệ thống dịch vụ máy chủ cao hơn, chất lượng hơn và ổn định hơn Như vậy việc chú trọng nhiều hơn đối với các hệ thống ứng dụng phát triển và hoạt động trên máy chủ

để trang bị cho hoạt động kinh doanh có nghĩa là các dịch vụ máy chủ đó cũng cần vận hành liên tục

Các ứng dụng quan trọng, như Website thương mại điện tử (TMDT), cơ sở

dữ liệu (CSDL) doanh nghiệp và email, thường cần được ưu tiên đặt trong các hệ thống máy chủ lớn và cấu trúc mạng được thiết kế có tính sẵn sàng cao Điều này cũng đúng với các Website bán lẻ và các hoạt động kinh doanh trên nền web khác Các nhà cung cấp dịch vụ nhận ra rằng cần phải lên kế hoạch và cấu hình hệ thống máy chủ dịch vụ của mình với tính sẵn sàng cao, để có thể có một hệ thống máy chủ cung cấp dịch vụ cho khách hàng của mình hoạt động ổn định, liên tục

1 Khái niệm về tính sẵn sàng

1.1 Tính sẵn sàng hệ thống

Tính sẵn sàng là tỉ lệ giữa tổng thời gian khả dụng và tổng thời gian cho

trước của một đơn vị chức năng (“The ratio of (a) the total time a functional

unit is capable of being used during a given interval to (b) the length of the interval.”)

Tính sẵn sàng cao là một thiết kế hệ thống tiếp cận và triển khai các dịch vụ liên quan đảm bảo mức độ hiệu suất hoạt động được chuẩn bị trước của hệ thống

sẽ được đáp ứng trong khoảng thời gian hợp đồng (“High availability is a system

design approach and associated service implementation that ensures a prearranged level of operational performance will be met during a contractual measurement period”)

Người dùng muốn hệ thống của họ ví dụ bệnh viện, máy bay, hay máy tính luôn sẵn sàng phục vụ họ tất cả thời gian Tính sẵn sàng đề cập tới khả năng của người dùng giao tiếp để truy cập vào hệ thống, bất cứ khi nào có công việc mới, cập nhật hoặc thay đổi công việc hiện tại, hoặc thống kê báo cáo từ các công việc trước Nếu người dùng không truy cập vào hệ thống, người ta gọi đó là không sẵn sàng (unavailable) Thông thường, thuật ngữ downtime dùng để chỉ khoảng thời

gian khi hệ thống không sẵn sàng

1.2 Thời gian downtime có tính toán và không có tính toán

Sự khác biệt có thể tạo ra giữa thời gian dự đoán và thời gian không dự đoán được Thông thường, thời gian downtime dự đoán được là kết quả của quá trình bảo trì mà làm gián đoạn hoạt động hệ thống và thường xảy ra với thiết kế hệ thống hiện tại Các sự kiện gây ra thời gian downtime dự đoán được có thể bao gồm các bản vá đối với phần mềm hệ thống hoặc thay đổi cấu hình mà chỉ có tác dụng khi cần phải khởi động lại hệ thống Nói chung, thời gian dự đoán được là kết quả của các sự kiện logic, quản lý được Các sự kiện gây ra thời gian downtime không dự đoán được thường được tạo ra từ các sự kiện vật lý như phần cứng, hoặc phần mềm bị lỗi, hay bị ảnh hưởng bởi môi trường Ví dụ các sự kiện gây thời gian downtime không dự đoán được như mất nguồn, lỗi CPU, RAM, nhiệt độ quá cao dẫn tới tắt máy, mất kết nối mạng, hoặc lỗi ứng dụng hệ điều hành

Nhiều trang web cho rằng thời gian downtime có thể dự đoán được không nên cho vào việc tính toán tính sẵn sàng cho hệ thống bởi vì nó không dựa trên việc giao tiếp với người dùng Nếu bỏ qua thời gian downtime có thể dự đoán

được, rất nhiều hệ thống sẽ có hệ thống có tính sẵn sàng cao, vì nó biểu diễn thời gian hoạt động liên tục Các hệ thống có tính sẵn sàng cao thật sự ít có sự so sánh

và giá thành thường cao hơn, và hầu hết có một thiết kế đặc biệt mà có thể xác định bất cứ điểm lỗi nào, cho phép phần cứng, mạng, hệ điều hành, và việc cập nhật ứng dụng các bản vá và sự thay thế Đối với các hệ thống chính, thời gian downtime dự đoán được không thành vấn đề, ví dụ, thời gian downtime của hệ thống văn phòng xảy ra vào ban đêm khi mọi người đã về nhà hết

1.3 Tính toán độ sẵn sàng

Độ sẵn sàng thường được biểu diễn bởi thời gian khả dụng tính trên một năm Bảng sau đưa ra thời gian downtime có thể cho phép đối với phần trăm cụ thể, với giả thuyết rằng hệ thống được yêu cầu hoạt động liên tục Hợp đồng về dịch vụ thường đề xuất thời gian downtime hoặc tính sẵn sàng theo tháng, để tính toán giá dịch vụ kết hợp với việc xoay vòng cước hàng tháng

Tính sẵn sàng % Downtime /năm Downtime/ Tháng Downtime/tuần

90% ("one nine") 36.5 days 72 hours 16.8 hours

95% 18.25 days 36 hours 8.4 hours

97% 10.96 days 21.6 hours 5.04 hours

98% 7.30 days 14.4 hours 3.36 hours

99% ("two nines") 3.65 days 7.20 hours 1.68 hours

99.5% 1.83 days 3.60 hours 50.4 minutes 99.8% 17.52 hours 86.23 minutes 20.16 minutes 99.9% ("three nines") 8.76 hours 43.8 minutes 10.1 minutes 99.95% 4.38 hours 21.56 minutes 5.04 minutes 99.99% ("four nines") 52.56 minutes 4.32 minutes 1.01 minutes 99.999% ("five nines") 5.26 minutes 25.9 seconds 6.05 seconds 99.9999% ("six nines") 31.5 seconds 2.59 seconds 0.605 seconds

99.99999% ("seven nines") 3.15 seconds 0.259 seconds 0.0605 seconds

Bảng 1: Tính sẵn sàng và thời gian downtime

Thời gian khả dụng và tính sẵn sàng không đồng nhất Một hệ thống có thể vẫn hoạt động nhưng không sẵn sàng trong trường hợp mạng bị lỗi Nói chung, các

số 9 thường không được dùng bởi các kỹ sư mạng khi mô hình hóa và đo độ sẵn sàng Mà thông thường độ sẵn sàng thường được biểu diễn như một đơn vị xác suất, hoặc thời gian downtime mỗi năm Độ sẵn sàng đo bởi các con số 9 thường được nhìn thấy qua các văn bản thương mại

1.4 Phép đo và sự lý giải

Rõ ràng rằng, tính sẵn sàng được đo như thế nào là chủ đề của một số phương pháp lý giải Một hệ thống hoạt động ổn định trong 365 ngày có thể bị bỏ qua bởi một lỗi mạng kéo dài 9 giờ trong khoảng thời gian cao điểm, người dùng coi hệ thống không thể truy cập, trong khi hệ thống lại khẳng định rằng uptime 100% Một hệ thống gặp vấn đề về hiệu năng thường được coi là không sẵn sàng cục bộ hoặc toàn diện đối với người dùng, thậm chí hệ thống tiếp tục thực hiện các chức năng

Tính sẵn sàng phải được xác định cùng với công cụ giám sát mà bản thân chúng cũng phải có tính sẵn sàng cao

1.5 Các nhân tố gây ra tính không sẵn sàng của hệ thống

- Mất kiểm soát việc tác động đến hệ thống

- Thiếu giám sát các thành phần có liên quan

- Thiếu các tiêu chí đánh giá hoặc sử dụng thiết bị kém chất lượng

- Quản lý việc vận hành chưa tốt

- Thiếu việc kiểm soát tránh lỗi về mạng

- Thiếu kiểm soát lỗi ứng dụng

- Thiếu kiểm soát môi trường phần cứng

Thiếu việc dự phòng mạng

- Thiếu các giải pháp kỹ thuật backup

- Thiếu vị trí đặt các thiết bị phần cứng

- Thiếu dự phòng về hạ tầng

- Thiếu kiến trúc dự phòng dung lượng

1.6 Các khái niệm liên quan

Thời gian khôi phục hay thời gian sửa chữa (recovery time) là khái niệm gần với tính sẵn sàng Đó là tổng thời gian được yêu cầu cho việc dừng có kế hoạch hoặc tổng thời gian yêu cầu cho việc khôi phục từ việc dừng không được dự báo trước Thời gian khôi phục có thể là vô hạn đối với kiến trúc bị lỗi, ví dụ lỗi hỏa hoạn động đất phá hủy trung tâm dữ liệu và hệ thống của nó trong khi không

có một hệ thống thứ 2 dự phòng

Một khái niệm liên quan nữa là tính sẵn sàng dữ liệu Đó là mức độ sẵn sàng đối với cơ sở dữ liệu, hoặc các hệ thống lưu trữ dữ liệu lưu trữ và báo cáo về các giao dịch dữ liệu Quản lý thông tin đặc biệt thường tập trung vào tính sẵn sàng

dữ liệu để xác định khả năng mất dữ liệu có thể chấp nhận được với các sự kiện lỗi khác nhau Một số người dùng có thể chấp nhận không dùng dịch vụ, nhưng không chấp nhận mất dữ liệu

2 Phân loại

Tính sẵn sàng là một ưu tiên hàng đầu của các doanh nghiệp, đặc biệt là các

doanh nghiệp cung cấp dịch vụ trực tuyến với khách hàng Các doanh nghiệp luôn được yêu cầu nâng cao tính sẵn sàng cho các máy chủ và đáp ứng khối lượng công việc ở mức độ khác nhau, từ mức cơ bản của việc sử dụng nhiều thành phần phần cứng cho tới những phương pháp tập trung nhất của việc phân cụm (clustering) Các nội dung mà các doanh nghiệp luôn hướng tới:

- Sẵn sàng về ứng dụng

- Sẵn sàng về thiết bị

- Sẵn sàng về dữ liệu

- Sẵn sàng về mạng

3.1 Sẵn sàng về ứng dụng

Microsoft đã và đang triển khai nhiều tính năng và công nghệ nhằm tăng tính bảo mật của các máy chủ chạy windows server 2008, cũng như làm tăng hiệu năng và giảm chi phí sở hữu

Failover Clustering là một trong những tính năng quan trọng nhằm nâng cao tính sẵn sàng của các ứng dụng Nó mang lại tính sẵn sàng và khả năng tùy biến cao cho các ứng dụng Khi một node lỗi, một node khác ngay lập tức được online

để thay thế Quá trình này được gọi là dự phòng lỗi ( failover) Nó hoàn toàn trong suốt với người dùng Những ai đang truy cập dịch vụ tiếp tục truy cập dịch vụ và không biết được rằng hiện dịch vụ đang được cung cấp từ một máy chủ (node) khác

2.2 Sẵn sàng về thiết bị phần cứng

Phần cứng đóng một vai trò quan trọng trong việc phát triển hệ thống Một giải pháp phần cứng hiệu quả sẽ làm tăng rất nhiều tính sẵn sàng cho hệ thống Các giải pháp có thể đi từ đơn giản đến phức tạp

Các thành phần dự phòng: Chúng ta có thể giảm thiểu thời gian downtime với các thành phần tin cậy và có chất lượng cao ít xảy ra lỗi Chúng ta có thể thêm các thành phần dự phòng trong trường hợp xảy ra lỗi

Để tăng cường tính sẵn sàng của phần cứng, một số phiên phản của windows server, như windows server 2008 enterprise, windows server 2008 datacenter được thiết kế để hỗ trợ đầy đủ tính chịu lỗi của máy chủ Máy chủ chịu lỗi là máy chủ có độ dự phòng hoàn toàn với tất cả các thành phần phần cứng Nếu thành phần chính bị lỗi, thành phần thứ hai sẽ tiếp tục đảm nhận công việc xử lý tiếp các tiến trình mà các ứng dụng chạy trên server không hề bị ảnh hưởng Trong

tầng phần cứng (hardware), điều đó khiến các lỗi phần cứng trong suốt với ứng dụng Ngoài ra microsoft còn tăng cường khả năng sẵn sàng của máy chủ và tính chịu lỗi với phân vùng phần cứng tự động (dynamic hardware partitioning) Windows làm việc với từng thành phần phần cứng riêng, mỗi thành phần lại có CPU, RAM và việc đọc ghi độc lập với các thành phần phần cứng khác Chúng ta

có thể, thêm hoặc thay thế các thành phần phần cứng mà không cần phải khởi động lại hệ thống Điều này làm tăng độ tin cậy tính sẵn sàng đối với máy chủ

2.3 Sẵn sàng về dữ liệu

Độ tin cậy về phần cứng giúp các máy chủ đơn có tính sẵn sàng cao Tính sẵn sàng cao còn được thể hiện về mặt dữ liệu Đơn cử là windows Exchange 2007

và SQL 2005

a/ Tính sẵn sàng cao của Exchange 2007

Microsoft Exchange 2007 có nhiều cách để mang lại tính sẵn sàng cao cho

hạ tầng nhắn tin Local Continuous Replication (LCR) là một giải pháp đơn máy chủ sử dụng công nghệ log shipping bất đối xứng tích hợp sẵn để tạo ra và duy trì một bản lưu trữ trên một bộ đĩa thứ hai được kết nối vào cùng một máy chủ như là nhóm lưu trữ sản xuất LCR cung cấp log shipping, log replay, và việc chuyển dịch thủ công nhanh chóng đến bản dữ liệu thứ hai

Hình 1: Local Continuous Replication

Cluster Continuous Replication (CCR) là một giải pháp nhóm sử dụng công nghệ log shipping bất đối xứng tích hợp để tạo ra và duy trì một nhóm lưu trữ trên một máy chủ thứ hai CCR được thiết kế để làm một hoặc hai giải pháp trung tâm

dữ liệu, mang lại tính sẵn sàng cao và khả năng phục hồi của site CCR, là một giải pháp failover cluster lưu trữ không chia sẻ, là một trong hai dạng triển khai máy chủ mailbox theo nhóm có trong Microsoft Exchange Server 2007 (dạng còn lại là phân cụm đơn bản, được mô tả dưới đây)

Hình 2: Cluster Continuous Replication

Single Copy Clusters (SCC) là một giải pháp nhóm sử dụng một bản của nhóm dữ liệu cho dữ liệu được chia sẻ giữa các nút trong nhóm SSC rất giống với phân cụm trong các phiên bản của Exchange Server trước đây, với một số thay đổi

và cải tiến đáng kể SSC, một giải pháp lưu trữ failover cluster chia sẻ, là một trong hai dạng triển khai máy chủ mailbox theo nhóm có trong Microsoft Exchange Server 2007

Hình 3: Single Copy Cluster

Standby Continuous Replication (SCR) là một tính năng mới được giới thiệu trong Exchange Server 2007 Service Pack 1 (SP1) SCR được thiết kế cho các điều kiện cụ thể sử dụng hoặc cho phép sử dụng các máy chủ phục hồi đang ở chế độ standby SCR mở rộng các tính năng sao chép hiện có và cho phép độ các điều kiện sẵn sàng dữ liệu mới đối với các máy chủ mailbox Exchange Server

2007 SCR sử dụng cùng công nghệ log shipping và replay mà LCR và CCR sử dụng để cung cấp các lựa chọn và cấu hình triển khai bổ sung bằng cách cung cấp cho quản trị viên khả năng tạo ra các bản nhóm lưu trữ bổ sung SCR có thể được

sử dụng để sao chép dữ liệu từ máy chủ mailbox độc lập hoặc máy chủ mailbox nhóm

Hình 4: StandbyContinuous Replication

sở hữu Lợi ích của phản chiếu CSDL bao gồm bảo vệ dữ liệu bằng cách cung cấp

dự phòng hoàn toàn hoặc gần như hoàn toàn, tăng tính sẵn sàng của CSDL trong trường hợp thảm họa, và cải thiện tính sẵn sàng của một CSDL sản xuất trong khi nâng cấp

• Failover Clustering

Failover Clustering mang lại sự hỗ trợ có tính sẵn sàng cao cho toàn bộ các thực thể của SQL Server Các ứng dụng như SQL Server và Notification Services

được cài đặt vào một nhóm Server Cluster, được gọi là nhóm tài nguyên Bất cứ khi nào, mỗi nhóm tài nguyên này chỉ được sở hữu bởi chỉ một nút trong nhóm Dịch vụ ứng dụng có một tên ảo độc lập với các tên nút, và được biết tới là tên thực thể của failover cluster Một ứng dụng có thể kết nối với thực thể của failover cluster bằng cách tham chiếu tên thực thể của failover cluster; nó không cần biết đến nút nào host thực thể của failover cluster

• Log Shipping

Giống như database mirroring, log shipping hoạt động ở cấp độ CSDL Log shipping cung cấp dự phòng ở cấp độ CSDL với một hoặc hai thực thể của SQL Server Nó sử dụng các công việc được lên kế hoạch để tự động sao lưu, copy và phục hồi các log giao dịch để duy trì các bản copy thứ cấp của cơ sở dữ liệu trên một máy chủ standby Không giống như database mirroring, log shipping cho phép nhiều CSDL thứ cấp, điều mà tạo ra một giải pháp tốt hơn cho các ứng dụng đòi hỏi nhiều failover sites Log shipping có thể được cấu hình để cung cấp sự bảo vệ chống lại các lỗi sử dụng Sự trì hoãn về thời gian tạo ra một cửa sổ có thể ngăn chặn sự lây lan của lỗi con người tới máy chủ standby Log shipping cũng có thể được sử dụng để giảm tải trên máy chủ sơ cấp bằng cách sử dụng máy chủ thứ cấp cho việc xử lý các truy vấn chỉ đọc

• Sao chép

Sao chép sử dụng mô hình publish-subscribe, cho phép một máy chủ sơ cấp, được gọi là publisher, để phân phối dữ liệu đến một hoặc nhiều máy chủ thứ cấp, hay là các subscriber Sao chép tạo ra tính sẵn sàng thời gian thực và khả năng tùy biến trên khắp các máy chủ này Nó hỗ trợ lọc để cung cấp các bộ dữ liệu cho các subscriber, và cũng cho phép việc cập nhật được phân vùng Các subscriber trực tuyến và sẵn sàng cho việc báo cáo hoặc các chức năng khác mà không cần phục hồi truy vấn

2.4 Sẵn sàng về đường truyền mạng

Cân bằng tải mạng (network load balancer - NLB) tăng cường tính sẵn sàng bằng cách tận dụng sự giao tiếp lẫn nhau giữa các máy chủ NLB phân phối các yêu cầu từ các máy trạm tới các máy chủ một cách tuần tự hoặc theo một quy luật định sẵn Việc phân phối các yêu cầu của máy khách giữa các máy chủ cân bằng tải là trong suốt với các máy khách; đối với bất kỳ một máy trạm nào, các cụm

máy chủ giống như là một máy chủ đơn lẻ trả lời các yêu cầu từ các máy khách này

NLB là một phương thức hiệu quả, có khả năng tùy biến nhằm đạt được tính sẵn sàng cao hơn đối với các khối lượng giao dịch của máy chủ “stateless” Thuật ngữ “stateless” chỉ các giao dịch đáp lại yêu cầu của mỗi máy khách hoàn toàn độc lập với nhau Các yêu cầu của máy khách được giải quyết một cách tuần

tự hoặc song song nhưng không có tác động đến giao dịch hiện tại Một ví dụ cụ thể là một Web server Đối với mỗi máy khách yêu cầu một trang Web, Web server thu thập tất cả các thông tin cần thiết để lắp ráp các văn bản, hình ảnh và dữ liệu để mỗi máy khách có thể hiện thị một trang web riêng Máy chủ sau đó sẽ thu thập tất cả các thông tin nó cần cho một yêu cầu từ máy khách kế tiếp máy khách trước đó, và cứ như vậy Do mỗi yêu cầu của máy khách cung cấp tất cả các thông tin mà máy chủ “stateless” cần để hoàn thành giao dịch, để đáp ứng được tải hệ thống, các máy chủ nên chạy với một phân cụm NLB

hệ thống có tính sẵn sàng cao nhất gắn liền với một kiến trúc đơn giản, tuy nhiên, kiến trúc này chấp nhận yêu cầu rằng toàn bộ hệ thống phải dừng hoạt động để phục vụ cho việc cập nhật các bản vá và nâng cấp hệ điều hành Ngày càng nhiều các thiết kế hệ thống nâng cao, cho phép các hệ thống có thể cập nhật bản vá và nâng cấp hệ điều hành mà không làm ảnh hưởng đến tính sẵn sàng của dịch vụ

Tính sẵn sàng cao còn bao hàm việc không có sự can thiệp của con người làm thay đổi hay khôi phục lại hành động trong một hệ thống phức tạp Ví dụ, giới hạn tính sẵn sàng cao của 99,999% là cho phép downtime một giây mỗi ngày, mà không thực tế đối với tác động của con người Việc cần thiết có can thiệp của con người đối với hoạt động bảo trì trong một hệ thống lớn sẽ làm phóng đại giới hạn này Giới hạn tính sẵn sàng của 99% cho phép downtime 15 phút mỗi ngày, sẽ thực tế hơn với những tác động mang tính chủ quan

Tính dư thừa được sử dụng để tạo ra hệ thống cùng với các mức độ cao của tính sẵn sàng Trong trường hợp này nó yêu cầu phải có mức độ phát hiện lỗi cao

và giảm thiểu đến mức thấp nhất các lỗi thông thường Có 2 loại dư thừa, dư thừa

bị động (passive redundancy) và dư thừa chủ động (active redundancy)

Tính dư thừa bị động được sử dụng để đạt được tính sẵn sàng cao bao gồm khả năng đủ ngưỡng trong thiết kế để làm cân bằng sự sụt giảm về hiệu suất Một

ví dụ cụ thể như sau: một con thuyền có hai động cơ riêng biệt phục vụ cho 2 bánh lái riêng biệt Con thuyền sẽ tiếp tục thẳng tới đích nếu không có sự cố xảy ra đối với động cơ hoặc bánh lái Vấn đề phức tạp hơn là sự dư thừa về thiết bị nguồn bên trong một hệ thống lớn bao gồm việc truyền tải năng lượng Các trục trặc của một thành phần đơn không được coi là một lỗi nếu nó không gây ra việc suy giảm hiệu năng của toàn bộ hệ thống vượt quá mức cho phép

Tính dư thừa chủ động được sử dụng trong các hệ thống phức tạp để đạt được tính sẵn sàng cao không làm suy giảm hiệu năng hệ thống Các hệ thống được thiết kế để có thể phát hiện được lỗi hoặc tự động cấu hình lại hệ thống bỏ qua các lỗi nhỏ Điều này được sử dụng trong một hệ thống tính toán phức tạp

nhưng lại có mối liên kết với nhau Tính dư thừa chủ động có thể đưa ra các mô hình lỗi phức tạp

Thiết kế hệ thống không downtime tức là việc mô hình hóa và sự mô phỏng chỉ ra thời gian xảy ra lỗi không vượt quá thời gian giữa việc bảo trì có kế hoạch

và các sự kiện nâng cấp, hoặc vòng đời hệ thống Việc thiết kế này bao gồm cả sự

dư thừa bị động

Công cụ phát hiện lỗi được sử dụng trong các hệ thống có tính dư thừa thấp

để đạt được tính sẵn sàng cao Các hoạt động bảo trì xảy ra trong khoảng thời gian ngắn của downtime chỉ sau khi lỗi được phát hiện

Việc mô hình hóa và mô phỏng được sử dụng để ước lượng độ thực tế lý thuyết đối với hệ thống lớn Kết quả sẽ được sử dụng để đánh giá các lựa chọn thiết kế khác Mô hình của toàn bộ hệ thống sẽ được tạo ra, và mô hình sẽ được cô đọng lại bằng cách loại bỏ các thành phần Mô phỏng độ dư thừa bao gồm tiêu chuẩn N - x N đại diện cho tổng số thành phần trong hệ thống x là số thành phần trọng tâm của hệ thống N – 1 nghĩa rằng mô hình được đảm bảo với 1 thành phần

bị lỗi N – 2 là mô hình được đảm bảo với 2 thành phần bị lỗi

3.2 Mô hình failover cơ bản

• Cấu hình không đối xứng hay cấu hình active/standby

Trong cấu hình không đối xứng, ứng dụng chạy trên một máy chủ chính Một máy chủ dự phòng sẵn sàng cho việc thay thế với bất kỳ lỗi nào xảy ra Máy chủ dự phòng này không cấu hình để thực hiện bất cứ chức năng gì Trong hình minh họa dưới đây, ứng dụng sẽ được di chuyển từ máy chủ chính sang máy chủ

dự phòng

Hình 5: Cấu hình bất đối xứng

Cấu hình này là đơn giản nhất và cũng là đáng tin cậy nhất Máy chủ dự phòng luôn ở trạng thái standby và có đẩy đủ chức năng giống máy chủ chạy chính

• Cấu hình đối xứng hay cấu hình active/active

Trong cấu hình đối xứng mỗi máy chủ được cấu hình để chạy một ứng dụng hay một dịch vụ cụ thể và nó cung cấp tính dự phòng cho máy chủ còn lại Trong hình dưới, mỗi máy chủ chạy một ứng dụng, khi một máy chủ bị lỗi, máy chủ còn lại sẽ chạy cả hai ứng dụng

Hình 6: Cấu hình đối xứng

Việc sử dụng hiệu quả tài nguyên phần cứng được thể hiện rõ hơn trong cấu hình đối xứng Trong ví dụ về cấu hình đối xứng, máy chủ dự phòng chỉ cần có bộ

xử lý mạnh như máy chủ chạy chính, khi có lỗi xảy ra, máy chủ dự phòng sẽ lên thay thế và hiệu suất hệ thống vẫn giữ nguyên Nhưng trong cấu hình bất đối xứng, máy chủ dự phòng phải có cấu hình đủ mạnh để ngoài việc chạy ứng dụng của bản thân nó, nó còn phải chạy thêm ứng dụng mới

Xa hơn, một vấn đề có thể được đưa ra trong cấu hình đối xứng, đó là nhiều ứng dụng chạy trên cùng một hệ thống không thể tồn tại Vấn đề xảy ra khi hai ứng dụng có việc đọc ghi khác nhau và yêu cầu về bộ nhớ cũng khác nhau chạy trên cùng một hệ thống

sẽ được nối với tất cả các bộ lưu trữ và hoạt động khi lỗi xảy ra

Vấn đề trong thiết kế này là failback Khi một máy chủ bị lỗi được sửa lại, tất cả các ứng dụng mà nó sở hữu phải được trả lại cho máy chủ Hành động failback sẽ giải phóng máy chủ dự phòng và khôi phục tính dự phòng cho cluster

Hình 8: Cấu hình N – 1 khi có lỗi

Thông thường, kiến trúc này được sử dụng trong trường hợp có hữu hạn thiết bị lưu trữ

3.3 Cấu hình failover nâng cao

• Cấu hình N + 1

Với việc sử dụng SANs (storage area networks), ta không chỉ tạo ra một nhóm máy chủ lớn mà có thể kết nối nhiều máy chủ vào cùng một bộ lưu trữ

Hình 9: Cấu hình N+ 1

Một máy chủ dự phòng là không cần trong cấu hình này Thay vào mô hình

N – 1, chúng ta có thể sử dụng mô hình N + 1, lợi thế của mô hình này là có thêm một máy chủ chỉ làm công tác dự phòng

Khi một máy chủ bị lỗi, ứng dụng sẽ được khởi động lại trên máy chủ dự phòng Sau khi máy lỗi được sửa xong thì nó sẽ trở thành máy chủ dự phòng Mô hình này loại trừ khả năng ứng dụng thứ hai bị lỗi và phải failback lại máy chủ chạy chính Bất cứ máy chủ nào cũng có khả năng cung cấp dự phòng cho bất cứ máy chủ khác

Hình 10: Cấu hình N + 1 khi có lỗi

Mô hình này là sự mở rộng của mô hình N + 1 Nó cung cấp một cụm máy chủ có khả năng standby, thay vì chỉ một máy chủ

Mô hình này yêu cầu việc kiểm tra thật cẩn thận, để đảm bảo rằng tất cả các ứng dụng đều tương thích Các ứng dụng cũng phải được điều khiển hoàn toàn khi có lỗi xảy ra

3.4 Mô hình cluster và bộ lưu trữ

• Cụm bộ lưu trữ chia sẻ cơ bản

Trong cấu hình này, một cụm đơn chia sẻ sự truy cập tới thiết bị lưu trữ, thông thường thông qua SAN Một ứng dụng chỉ có thể được khởi động trên một node với việc truy cập vào storage được yêu cầu Ví dụ, trong một cụm nhiều node, bất cứ node nào được thiết kế để chạy một instance cụ thể phải truy cập tới storage nơi tablespace của database, redo logs và control files được lưu trữ Kiến trúc ổ đĩa được chia sẻ là kiến trúc dễ nhất để thực thi và bảo trì Khi một node hoặc ứng dụng lỗi, tất cả dữ liệu được yêu cầu start trên một node khác được chứa trên các ổ cứng chia sẻ

Hình 12: Cụm lưu trữ chia sẻ cơ bản

• Cụm lưu trữ chia sẻ lớn

Trong môi trường lớn, VCS (Veritas Cluster Server ) và VVM (Veritas Volume Manager) được sử dụng để tạo tạo ra một cụm mà trải dài trên nhiều trung tâm dữ liệu và tòa nhà Thay vì sử dụng mảng storage đơn, dữ liệu được sao chép giữa các mảng sử dụng Veritas Volume Manager Mô hình này cho phép sao chép đồng thời dữ liệu ở các site

Hình 13: Cụm lưu trữ chia sẻ lớn

Mô hình cluster này yêu cầu 2 đường liên kết mạng độc lập cho heartbeat, hai mảng lưu trữ mà mỗi mảng cung cấp các ổ cứng có tính sẵn sàng cao và kết nối mạng public giữa các tòa nhà trên cùng một subnet Nếu cluster chạy trên nhiều subnet khác nhau, cần đến một chế độ phân giải tên miền để điều khiển sự thay đổi mạng

• Cluster không chia sẻ

Các hệ thống trong mô hình cluster không chia sẻ truy câp vào các đĩa, chúng lưu trữ các bản sao dữ liệu một cách riêng rẽ Mô hình này thông thường có

dữ liệu chỉ đọc được lưu trữ trên ổ local trên cả hai hệ thống Ví dụ, một cặp hệ thống trong một cluster mà bao gồm máy chủ web, mà cung cấp truy cập tới database ở phía sau Máy chủ web chạy trên ổ đĩa local và không yêu cầu chia sẻ

dữ liệu ở mức máy chủ web

Hình 14: Cụm lưu trữ không chia sẻ

• Cụm dữ liệu được đồng bộ

Trong cụm dữ liệu được đồng bộ không có ổ đĩa được chia sẻ Thay vào đó,

dữ liệu được sao chép đồng thời trên tất cả các node Đồng bộ có thể đặt ở mức ứng dụng, máy chủ hoặc mức lưu trữ Sản phẩm của đồng bộ mức ứng dụng, ví dụ oracle dataguard, duy trì các bản copy dữ liệu giữa các hệ thống ở mức sql hoặc database Sản phẩm đồng bộ dựa vào máy chủ, ví dụ như veritas volume replicator, duy trì các storage ở mức logical volume Sản phẩm đồng bộ dựa vào storage duy trì các bản sao dữ liệu ở mức ổ đĩa hay RAID LUN

Hình sau minh họa cụm dữ liệu đồng bộ chia sẻ phân tầng:

PHẦN B

HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU

Thiết bị phần cứng, đường truyền mạng và cơ sở dữ liệu là những thành phần không thế thiếu trong một hệ thống dịch vụ bất kỳ Đảm bảo tính sẵn sàng của mỗi thành phần này là một nhiệm vụ quan trọng của bất kỳ quản trị viên nào Trong phần tiếp theo của luận văn sẽ trình bày về tính sẵn sàng của hệ quản trị cơ

sở dữ liệu

1 Tính sẵn sàng trong hệ quản trị cơ sở dữ liệu

Độ tin cậy, khả năng khôi phục, và tính liên tục của hoạt động là 3 tính năng của một giải pháp nâng cao tính sẵn sàng

Độ tin cậy: Phần cứng tin cậy là một thành phần của giải pháp nâng cao tính sẵn

sàng Phần mềm tin cậy, bao gồm database, máy chủ web, và ứng dụng quan trọng như việc thực thi một giải pháp nâng cao tính sẵn sàng

Khả năng khôi phục: Có rất nhiều lựa chọn cho việc phục hồi hệ thống từ một lỗi

Điều quan trọng là xác định được lỗi có thể xảy ra và làm thế nào để khôi phục lỗi trong khoảng thời gian cho phép của hệ thống

Khả năng phát hiện lỗi: Nếu một thành phần trong kiến trúc hệ thống bị lỗi thì

việc phát hiện lỗi nhanh là một thành phần cơ bản khác trong việc phục hồi hệ thống từ một lỗi không mong đợi có thể xảy ra Giám sát tình trạng hoạt động của

hệ thống yêu cầu một công cụ đáng tin cậy để kiểm tra nó nhanh chóng và có khả năng thông báo cho người quản trị vấn đề có thể xảy ra

Khả năng hoạt động liên tục: Khi thực hiện các công tác bảo trì thì việc truy cập

vào dữ liệu vẫn được diễn ra với rất nhỏ hoặc không có downtime là điều cần thiết Giống như việc thêm CPU vào một máy chủ nên trong suốt với người dùng cuối trong kiến trúc nâng cao tính sẵn sàng