Khái niệm về tính sẵn sàng
Tính sẵn sàng hệ thống
Availability is the ratio of the total time a functional unit can be utilized during a specific interval to the total length of that interval.
High availability refers to a system design strategy and service implementation that guarantees a predetermined level of operational performance throughout a specified contractual period This approach ensures that services remain accessible and functional, minimizing downtime and enhancing reliability for users.
Người dùng, như trong bệnh viện, máy bay hay máy tính, mong muốn hệ thống luôn sẵn sàng phục vụ 24/7 Tính sẵn sàng đề cập đến khả năng người dùng truy cập vào hệ thống để thực hiện công việc mới, cập nhật hoặc thay đổi công việc hiện tại, cũng như lấy thống kê báo cáo từ các công việc trước Khi người dùng không thể truy cập vào hệ thống, điều này được gọi là không sẵn sàng (unavailable) Thuật ngữ downtime thường được sử dụng để chỉ thời gian hệ thống không hoạt động.
Thời gian downtime có tính toán và không có tính toán
Sự khác biệt giữa thời gian downtime dự đoán và không dự đoán được thường liên quan đến nguyên nhân gây ra chúng Thời gian downtime dự đoán được thường xuất phát từ quá trình bảo trì hệ thống, như cập nhật phần mềm hoặc thay đổi cấu hình, và thường là kết quả của các sự kiện logic có thể quản lý Ngược lại, thời gian downtime không dự đoán được thường do các sự kiện vật lý gây ra, chẳng hạn như lỗi phần cứng, phần mềm, hoặc yếu tố môi trường Ví dụ về downtime không dự đoán được bao gồm mất nguồn, lỗi CPU, RAM, nhiệt độ quá cao, 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 và điều này cần được tính toán khi đánh giá tính sẵn sàng của hệ thống, vì nó không phụ thuộc vào giao tiếp với người dùng Nếu bỏ qua thời gian downtime có thể dự đoán, nhiều hệ thống sẽ có tính sẵn sàng cao hơn, thể hiện qua thời gian hoạt động liên tục Các hệ thống có tính sẵn sàng cao thường ít được so sánh và có chi phí cao hơn, với thiết kế đặc biệt giúp xác định điểm lỗi, cho phép bảo trì phần cứng, mạng, hệ điều hành và cập nhật ứng dụng Đối với các hệ thống chính, thời gian downtime dự đoán không phải là vấn đề, như trong trường hợp hệ thống văn phòng thường ngừng hoạt động vào ban đêm khi không có người sử dụng.
Tính toán độ sẵn sàng
Độ sẵn sàng của hệ thống thường được biểu diễn qua thời gian khả dụng trong một năm, với bảng dưới đây cho thấy thời gian downtime cho phép dựa trên các
Tính sẵn sàng % Downtime/nămDowntime/ Tháng Downtime/tuần
90% ("one nine") 36.5 days 72 hours 16.8 hours
99% ("two nines") 3.65 days 7.20 hours 1.68 hours
99.9% ("three nines") 8.76 hours 43.8 minutes 10.1 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 của hệ thống không đồng nhất, vì 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 gặp sự cố Các kỹ sư mạng thường không sử dụng các số 9 để mô hình hóa và đo độ sẵn sàng Thay vào đó, độ sẵn sàng thường được thể hiện dưới dạng xác suất hoặc thời gian ngừng hoạt động hàng năm Các con số 9 thường được sử dụng để đo độ sẵn sàng trong các văn bản thương mại.
Phép đo và sự lý giải
Tính sẵn sàng của hệ thống được đo bằng nhiều phương pháp khác nhau, và một hệ thống có thể hoạt động ổn định trong suốt 365 ngày nhưng vẫn bị coi là không thể truy cập nếu xảy ra lỗi mạng kéo dài 9 giờ trong thời gian cao điểm Người dùng có thể cảm thấy hệ thống không sẵn sàng mặc dù nó vẫn báo cáo uptime 100% Hơn nữa, một hệ thống gặp vấn đề về hiệu năng cũng có thể bị coi là không sẵn sàng, mặc dù nó vẫn thực hiện các chức năng nhất định.
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.
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.
Các khái niệm liên quan
Thời gian khôi phục (recovery time) là khái niệm liên quan đến tính sẵn sàng của hệ thống, bao gồm tổng thời gian cần thiết cho việc dừng có kế hoạch hoặc phục hồi từ sự dừng không dự báo trước Thời gian khôi phục có thể trở nên vô hạn trong trường hợp kiến trúc bị lỗi, chẳng hạn như khi một thảm họa như hỏa hoạn hoặc động đất phá hủy trung tâm dữ liệu và các hệ thống liên quan mà không có hệ thống dự phòng.
Tính sẵn sàng dữ liệu đề cập đến mức độ sẵn có của cơ sở dữ liệu và các hệ thống lưu trữ thông tin để báo cáo các giao dịch dữ liệu Quản lý thông tin thường tập trung vào khía cạnh này nhằm xác định mức độ mất dữ liệu chấp nhận được trong các tình huống lỗi khác nhau Trong khi một số người dùng có thể chấp nhận việc không sử dụng dịch vụ, họ lại không chấp nhận việc mất dữ liệu.
Phân loại
Sẵn sàng về ứng dụng
Microsoft đang nỗ lực cải thiện tính bảo mật cho các máy chủ Windows Server 2008 thông qua việc triển khai nhiều tính năng và công nghệ mới Đồng thời, công ty cũng tập trung vào việc nâng cao hiệu suất và giảm chi phí sở hữu cho người dùng.
Failover Clustering là tính năng quan trọng giúp nâng cao tính sẵn sàng cho các ứng dụng, mang lại khả năng tùy biến cao Khi một node gặp sự cố, một node khác sẽ ngay lập tức được kích hoạt để thay thế, quá trình này được gọi là dự phòng lỗi (failover) Điều này diễn ra hoàn toàn trong suốt với người dùng, cho phép họ tiếp tục truy cập dịch vụ mà không nhận thấy sự chuyển đổi sang máy chủ (node) khác.
Sẵn sàng về thiết bị phần cứng
Phần cứng là yếu tố quan trọng trong việc phát triển hệ thống, vì nó ảnh hưởng trực tiếp đến tính sẵn sàng của hệ thống Một giải pháp phần cứng hiệu quả có khả năng cải thiện đáng kể hiệu suất và độ tin cậy của hệ thống Các giải pháp phần cứng có thể đa dạng, từ những lựa chọn đơn giản đến những cấu hình phức tạp hơn.
Để giảm thiểu thời gian downtime, việc sử dụng các thành phần tin cậy và chất lượng cao là rất quan trọng Các thành phần dự phòng có thể được thêm vào để đảm bảo hoạt động liên tục khi có lỗi xảy ra Windows Server 2008 Enterprise và Datacenter được thiết kế để hỗ trợ tính chịu lỗi hoàn toàn, cho phép máy chủ duy trì hoạt động ngay cả khi một thành phần chính gặp sự cố Trong Windows Server 2008 Enterprise, khả năng chịu lỗi được quản lý bởi nhân (kernel) và phần cứng, giúp các lỗi phần cứng không ảnh hưởng đến ứng dụng Microsoft cũng đã cải thiện tính sẵn sàng và chịu lỗi của máy chủ thông qua phân vùng phần cứng tự động Hệ điều hành Windows có khả năng làm việc độc lập với từng thành phần phần cứng, cho phép thêm hoặc thay thế mà không cần khởi động lại hệ thống, từ đó nâng cao độ tin cậy và sẵn sàng cho máy chủ.
Sẵn sàng về dữ liệu
Độ tin cậy của phần cứng là yếu tố quan trọng giúp các máy chủ đơn đạt được tính sẵn sàng cao Tính sẵn sàng cao không chỉ thể hiện ở khả năng hoạt động liên tục mà còn ở việc bảo vệ dữ liệu Ví dụ điển hình là Windows Exchange 2007 và SQL Server 2005, trong đó Exchange 2007 nổi bật với khả năng duy trì tính sẵn sàng cao.
Microsoft Exchange 2007 cung cấp nhiều phương pháp để đảm bảo tính sẵn sàng cao cho hạ tầng nhắn tin, trong đó Local Continuous Replication (LCR) là giải pháp đơn máy chủ hiệu quả LCR sử dụng công nghệ log shipping bất đối xứng tích hợp sẵn để tạo và duy trì bản sao lưu trên một bộ đĩa thứ hai kết nối với cùng một máy chủ như nhóm lưu trữ sản xuất Giải pháp này hỗ trợ log shipping, log replay và cho phép chuyển dịch thủ công nhanh chóng đến bản dữ liệu thứ hai.
Cluster Continuous Replication (CCR) là giải pháp nhóm sử dụng công nghệ log shipping bất đối xứng để tạo và duy trì nhóm lưu trữ trên máy chủ thứ hai CCR mang lại tính sẵn sàng cao và khả năng phục hồi cho trung tâm dữ liệu Là một giải pháp failover cluster lưu trữ không chia sẻ, CCR là một trong hai phương thức triển khai máy chủ mailbox trong Microsoft Exchange Server 2007, bên cạnh phân cụm đơn bản.
Single Copy Clusters (SCC) là giải pháp nhóm cho phép sử dụng một bản dữ liệu chung giữa các nút trong nhóm, tương tự như phân cụm trong các phiên bản Exchange Server trước, nhưng có nhiều cải tiến SCC là một giải pháp lưu trữ failover cluster chia sẻ và là một trong hai hình thức triển khai máy chủ mailbox trong Microsoft Exchange Server 2007.
Standby Continuous Replication (SCR) là tính năng mới trong Exchange Server 2007 SP1, được thiết kế để sử dụng trong các điều kiện cụ thể với các máy chủ phục hồi ở chế độ standby SCR mở rộng khả năng sao chép hiện có, mang lại độ sẵn sàng dữ liệu cao hơn cho các máy chủ mailbox Exchange Server.
SCR, được phát triển vào năm 2007, sử dụng công nghệ log shipping và replay tương tự như LCR và CCR, mang đến cho quản trị viên khả năng tạo ra các bản sao lưu bổ sung Công nghệ này cho phép sao chép dữ liệu từ cả máy chủ mailbox độc lập và máy chủ mailbox nhóm, cung cấp thêm lựa chọn và cấu hình triển khai cho hệ thống.
Hình 4: StandbyContinuous Replication b/ Tính sẵn sàng cao của SQL 2005
Microsoft cam kết chặt chẽ về tính sẵn sàng CSDL với SQL Server, được nhấn mạnh bằng việc giới thiệu SQL Server Always On Technologies SQL Server
2005 Always On Technologies bao gồm:
• Sao chép Peer-to-peer
Database Mirroring là giải pháp phần mềm giúp tăng cường tính sẵn sàng của cơ sở dữ liệu (CSDL) bằng cách cung cấp khả năng dự phòng tức thời mà không làm mất dữ liệu Giải pháp này dễ dàng cài đặt và quản lý, không yêu cầu phần cứng đặc biệt Lợi ích của phản chiếu CSDL bao gồm bảo vệ dữ liệu với khả năng dự phòng gần như hoàn toàn, tăng cường tính sẵn sàng trong các tình huống thảm họa, và cải thiện khả năng sẵn sàng của CSDL trong quá trình nâng cấp.
Failover Clustering cung cấp khả năng sẵn sàng cao cho các thực thể của SQL Server, bao gồm cả SQL Server và Notification Services, được triển khai trong một nhóm Server Cluster gọi là nhóm tài nguyên Mỗi nhóm tài nguyên chỉ có thể được sở hữu bởi một nút trong nhóm tại một thời điểm Dịch vụ ứng dụng có tên ảo độc lập với tên các nút, được gọi là tên thực thể của failover cluster Ứng dụng có thể kết nối với thực thể của failover cluster bằng cách sử dụng tên thực thể này mà không cần biết nút nào đang lưu trữ nó.
Log shipping, tương tự như database mirroring, hoạt động ở cấp độ cơ sở dữ liệu (CSDL) và cung cấp giải pháp dự phòng cho một hoặc hai thực thể của SQL Server Nó sử dụng các công việc được lập lịch để tự động sao lưu, sao chép và phục hồi các log giao dịch, duy trì các bản sao thứ cấp trên máy chủ standby Khác với database mirroring, log shipping cho phép nhiều CSDL thứ cấp, là lựa chọn tối ưu cho các ứng dụng cần nhiều địa điểm failover Log shipping có thể được cấu hình để bảo vệ chống lại lỗi sử dụng, với sự trì hoãn thời gian tạo ra cửa sổ ngăn chặn sự lây lan lỗi từ người dùng tới máy chủ standby Ngoài ra, log shipping còn giúp giảm tải cho máy chủ chính bằng cách sử dụng máy chủ thứ cấp để xử lý các truy vấn chỉ đọc.
Mô hình publish-subscribe trong sao chép cho phép máy chủ chính (publisher) phân phối dữ liệu đến nhiều máy chủ phụ (subscribers), tạo ra tính sẵn sàng thời gian thực và khả năng tùy biến Nó hỗ trợ lọc dữ liệu cho các subscribers và cho phép cập nhật được phân vùng Các subscribers có thể trực tuyến và sẵn sàng cho 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.
Sẵn sàng về đường truyền mạng
Cân bằng tải mạng (NLB) nâng cao tính sẵn sàng bằng cách tối ưu hóa giao tiếp giữa các máy chủ NLB thực hiện việc phân phối yêu cầu từ các máy trạm tới các máy chủ theo cách tuần tự hoặc dựa trên quy tắc đã định Quá trình phân phối này diễn ra một cách trong suốt, khiến cho các máy khách cảm nhận cụm máy chủ như một máy chủ duy nhất, đáp ứng yêu cầu của họ một cách hiệu quả.
NLB (Network Load Balancing) là phương thức tối ưu giúp tăng cường tính sẵn sàng cho các giao dịch trên máy chủ "stateless" Thuật ngữ "stateless" đề cập đến các giao dịch mà mỗi yêu cầu từ máy khách hoàn toàn độc lập với nhau Các yêu cầu này có thể được xử lý tuần tự hoặc song song mà không ảnh hưởng đến giao dịch hiện tại Ví dụ điển hình là máy chủ Web, nơi mỗi máy khách yêu cầu một trang Web và máy chủ sẽ thu thập thông tin cần thiết để hiển thị nội dung riêng cho từng máy khách Để đáp ứng tải hệ thống hiệu quả, các máy chủ "stateless" cần hoạt động trong một cụm NLB.
Một số mô hình hệ thống hướng đến tính sẵn sàng
Thiết kế hệ thống có tính sẵn sàng cao
Nghịch lý trong thiết kế hệ thống là việc thêm nhiều thành phần có thể làm giảm tính sẵn sàng của hệ thống, do các hệ thống phức tạp thường chứa nhiều điểm lỗi tiềm ẩn Mặc dù một số nhà phân tích cho rằng kiến trúc đơn giản sẽ mang lại tính sẵn sàng cao hơn, nhưng điều này yêu cầu toàn bộ hệ thống phải dừng hoạt động để cập nhật bản vá và nâng cấp hệ điều hành Ngày nay, nhiều thiết kế hệ thống tiên tiến cho phép cập nhật mà không ảnh hưởng đến tính sẵn sàng của dịch vụ, cải thiện hiệu suất và độ tin cậy.
Tính sẵn sàng cao trong hệ thống phức tạp yêu cầu không có sự can thiệp của con người để duy trì hoặc phục hồi hoạt động Một mức độ sẵn sàng 99,999% cho phép downtime chỉ một giây mỗi ngày, nhưng điều này không thực tế khi xem xét tác động của con người Ngược lại, mức độ sẵn sàng 99% cho phép downtime 15 phút mỗi ngày, điều này thực tế hơn khi tính đến các yếu tố chủ quan và cần thiết phải có sự can thiệp trong quá trình bảo trì.
Tính dư thừa bị động là phương pháp quan trọng để đảm bảo tính sẵn sàng cao trong thiết kế, giúp cân bằng sự giảm sút hiệu suất Ví dụ, một con thuyền với hai động cơ riêng biệt và hai bánh lái độc lập vẫn có thể tiến về đích mà không gặp sự cố Trong các hệ thống lớn, như truyền tải năng lượng, sự dư thừa về thiết bị nguồn có thể giúp ngăn ngừa các trục trặc của một thành phần đơn không ảnh hưởng đến hiệu suất toàn hệ thống, miễn là mức suy giảm không vượt quá giới hạn cho phép.
Tính dư thừa chủ động đóng vai trò quan trọng trong các hệ thống phức tạp nhằm đảm bảo tính sẵn sàng cao mà không làm giảm hiệu suất Các hệ thống này được thiết kế để phát hiện lỗi và tự động cấu hình lại, giúp bỏ qua những lỗi nhỏ Điều này rất hữu ích trong các hệ thống tính toán phức tạp có sự liên kết chặt chẽ Hơn nữa, tính dư thừa chủ động có khả năng mô hình hóa các lỗi phức tạp, từ đó nâng cao độ tin cậy của hệ thống.
Thiết kế hệ thống không downtime đảm bảo rằng thời gian xảy ra lỗi không vượt quá khoảng thời gian giữa các lần bảo trì có kế hoạch và sự kiện nâng cấp Điều này bao gồm việc mô hình hóa và mô phỏng để tối ưu hóa hiệu suất hệ thống, đồng thời áp dụng sự dư thừa bị động nhằm tăng cường độ tin cậy và khả năng hoạt động liên tục của hệ thống.
Công cụ phát hiện lỗi đóng vai trò quan trọng trong các hệ thống có tính dư thừa thấp, giúp nâng cao tính sẵn sàng Việc bảo trì chỉ diễn ra trong thời gian ngắn sau khi lỗi được phát hiện, giảm thiểu downtime.
Mô hình hóa và mô phỏng là công cụ quan trọng để ước lượng tính thực tế lý thuyết của các hệ thống lớn, giúp đánh giá các lựa chọn thiết kế Toàn bộ hệ thống sẽ được mô hình hóa, sau đó cô đọng bằng cách loại bỏ các thành phần không cần thiết Mô phỏng độ dư thừa tuân theo tiêu chuẩn N x, trong đó N là tổng số thành phần của hệ thống và x là số thành phần quan trọng Cụ thể, N 1 đảm bảo mô hình với một thành phần bị lỗi, trong khi N 2 đảm bảo mô hình với hai thành phần bị lỗi.
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 hoạt động trên một máy chủ chính, trong khi một máy chủ dự phòng sẵn sàng thay thế khi có lỗi xảy ra Máy chủ dự phòng này không được cấu hình để thực hiện chức năng nào Khi xảy ra sự cố, ứng dụng sẽ được chuyển giao 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 và đáng tin cậy nhất, với máy chủ dự phòng luôn ở trạng thái chờ và có đầy đủ chức năng tương tự như máy chủ chính.
• Cấu hình đối xứng hay cấu hình active/active
Hình 6: Cấu hình đối xứng
Việc tối ưu hóa tài nguyên phần cứng thể hiện rõ qua cấu hình đối xứng, trong đó máy chủ dự phòng chỉ cần có bộ xử lý mạnh tương đương với máy chủ chính Khi xảy ra lỗi, máy chủ dự phòng sẽ tự động thay thế mà không làm giảm hiệu suất hệ thống Ngược lại, trong cấu hình bất đối xứng, máy chủ dự phòng cần có cấu hình mạnh hơn để không chỉ chạy ứng dụng của chính nó mà còn phải đảm nhận thêm ứng dụng khác.
Khi nhiều ứng dụng chạy trên cùng một hệ thống, vấn đề cấu hình đối xứng có thể phát sinh, đặc biệt khi hai ứng dụng có yêu cầu đọc ghi và bộ nhớ khác nhau Điều này dẫn đến xung đột và khó khăn trong việc duy trì hiệu suất hệ thống.
Một cấu hình failover N 1 giảm giá thành của việc sử dụng phần cứng nhưng vẫn – đảm bảo dự phòng
Cấu hình N – 1 cho phép một máy chủ dự phòng bảo vệ nhiều máy chủ hoạt động, giảm thiểu chi phí sử dụng Khi một máy chủ gặp lỗi, ứng dụng sẽ được chuyển sang máy chủ dự phòng So với cấu hình bất đối xứng 1 - 1, cấu hình 4 1 này chỉ sử dụng máy chủ dự phòng 25%, tiết kiệm đáng kể chi phí Máy chủ dự phòng kết nối với tất cả các bộ lưu trữ và hoạt động khi có sự cố xảy ra.
Trong thiết kế này, vấn đề chính là failback Khi một máy chủ bị lỗi được khôi phục, tất cả các ứng dụng liên quan cần được chuyển trở lại máy chủ đó Hành động failback không chỉ giải phóng máy chủ dự phòng mà còn khôi phục tính dự phòng cho cụm máy chủ.
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ữ.
Cấu hình failover nâng cao
Việc sử dụng SANs (mạng lưu trữ) cho phép kết nối nhiều máy chủ vào một hệ thống lưu trữ chung, tạo ra một nhóm máy chủ lớn và hiệu quả hơn trong quản lý dữ liệu.
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áy chủ gặp sự cố, ứng dụng sẽ tự động khởi động lại trên máy chủ dự phòng Sau khi khắc phục lỗi, máy chủ ban đầu sẽ trở thành máy chủ dự phòng Mô hình này giúp giảm thiểu khả năng ứng dụng thứ hai gặp lỗi và cần phải chuyển đổi lại về máy chủ chính Mọi máy chủ đều có khả năng cung cấp dự phòng cho bất kỳ máy chủ nào khác.
Hình 10: Cấu hình N + 1 khi có lỗi
Mô hình này áp dụng cho trường hợp nhiều ứng dụng chạy trên nhiều máy chủ Mỗi ứng dụng có khả năng failover trên các server khác
Trong cấu hình N – N, khi một máy chủ gặp sự cố, ứng dụng trên máy chủ đó sẽ tự động được khởi động lại trên một node khác Điều này giúp đảm bảo rằng không có máy chủ nào bị quá tải, duy trì hiệu suất và tính sẵn sàng của hệ thống.
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 đòi hỏi kiểm tra kỹ lưỡng để đảm bảo tất cả các ứng dụng tương thích, đồng thời cần có biện pháp kiểm soát triệt để khi xảy ra lỗi.
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 cụm đơn, các node chia sẻ quyền truy cập vào thiết bị lưu trữ qua SAN, cho phép một ứng dụng chỉ khởi động trên một node duy nhất với yêu cầu truy cập vào storage Trong một cụm nhiều node, bất kỳ node nào được thiết kế để chạy một instance cụ thể cần truy cập vào storage chứa tablespace, redo logs và control files của database Kiến trúc ổ đĩa chia sẻ là lựa chọn dễ dàng nhất để thực thi và bảo trì Khi một node hoặc ứng dụng gặp sự cố, tất cả dữ liệu cần thiết để khởi động trên node khác đều được lưu trữ 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 ra một cụm trải dài qua nhiều trung tâm dữ liệu và tòa nhà Thay vì chỉ sử dụng một mảng lưu trữ đơn lẻ, dữ liệu được sao chép giữa các mảng thông qua Veritas Volume Manager, cho phép sao chép đồng thời dữ liệu ở nhiều vị trí khác nhau.
Hình 13: Cụm lưu trữ chia sẻ lớn
Mô hình cluster yêu cầu hai đường liên kết mạng độc lập cho heartbeat, hai mảng lưu trữ với ổ cứng có tính sẵn sàng cao, và kết nối mạng công cộng giữa các tòa nhà trên cùng một subnet Nếu cluster hoạt động trên nhiều subnet khác nhau, cần thiết lập chế độ phân giải tên miền để quản lý sự thay đổi mạng.
Trong mô hình cluster, các hệ thống không chia sẻ truy cập vào đĩa mà lưu trữ bản sao dữ liệu riêng biệt Thông thường, dữ liệu chỉ đọc được lưu trữ trên ổ local của cả hai hệ thống Ví dụ, một cặp hệ thống trong cluster có thể bao gồm máy chủ web, cung cấp truy cập tới cơ sở dữ liệu ở phía sau Máy chủ web hoạt động trên ổ đĩa local và không cần 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 đồng bộ, không có ổ đĩa 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ể thực hiện ở mức ứng dụng, máy chủ hoặc lưu trữ Ví dụ, sản phẩm đồng bộ mức ứng dụng như Oracle Data Guard duy trì các bản sao dữ liệu giữa các hệ thống ở mức SQL hoặc cơ sở dữ liệu Sản phẩm đồng bộ dựa vào máy chủ, như Veritas Volume Replicator, duy trì các storage ở mức logical volume Cuối cùng, sản phẩm đồng bộ dựa vào lưu trữ duy trì các bản sao dữ liệu ở mức ổ đĩa hoặc RAID LUN.
Hình sau minh họa cụm dữ liệu đồng bộ chia sẻ phân tầng:
Hình 15: Cụm dữ liệu đồng bộ
Một global cluster liên kết các cluster ở các vị trí riêng rẽ và cho phép failover và khôi phục trên diện rộng
Local cluster cung cấp giải pháp local failover cho từng site hoặc tòa nhà, trong khi các cluster lớn hơn hoặc đồng bộ giúp bảo vệ trước các tác động của thảm họa trong khu vực hạn chế Những thảm họa lớn như lũ lụt, bão hay động đất có thể làm gián đoạn hoạt động của toàn bộ thành phố hoặc khu vực Trong những tình huống khẩn cấp này, bạn có thể đảm bảo tính sẵn sàng của dữ liệu bằng cách chuyển ứng dụng đến một site an toàn hơn.
Trong mô hình cluster toàn cầu, khi một ứng dụng hoặc hệ thống gặp lỗi, nó sẽ được chuyển sang hệ thống khác trong cùng một cluster Nếu toàn bộ cluster gặp sự cố, ứng dụng sẽ được di chuyển sang một hệ thống khác thuộc cluster khác Mô hình này yêu cầu việc đồng bộ dữ liệu tới các site ở xa để đảm bảo tính liên tục và ổn định cho ứng dụng.
PHẦN B NÂNG CAO TÍNH SẴN SÀNG TRONG
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 thiết yếu trong bất kỳ hệ thống dịch vụ nào Đảm bảo tính sẵn sàng cho mỗi thành phần này là nhiệm vụ quan trọng đối với quản trị viên Phần tiếp theo của luận văn sẽ tập trung vào việc phân tích tính sẵn sàng của hệ quản trị cơ sở dữ liệu.
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à ba yếu tố quan trọng trong giải pháp nâng cao tính sẵn sàng Độ tin cậy bắt nguồn từ phần cứng và phần mềm chất lượng, bao gồm cơ sở dữ liệu, máy chủ web và các ứng dụng quan trọng, tất cả đều góp phần vào việc thực hiện hiệu quả giải pháp này.
Khả năng khôi phục hệ thống từ lỗi rất đa dạng, và việc xác định nguyên nhân gây ra lỗi là điều quan trọng Bên cạnh đó, cần phải có kế hoạch phục hồi hiệu quả trong khoảng thời gian cho phép để đảm bảo hệ thống hoạt động ổn định.
Khả năng phát hiện lỗi trong hệ thống là yếu tố quan trọng để phục hồi từ sự cố không mong đợi Việc giám sát tình trạng hoạt động của hệ thống cần một công cụ đáng tin cậy, giúp kiểm tra nhanh chóng và thông báo kịp thời cho người quản trị về các vấn đề tiềm ẩn.
Khả năng hoạt động liên tục là yếu tố quan trọng trong công tác bảo trì, cho phép truy cập dữ liệu với rất ít hoặc không có thời gian ngừng hoạt động Điều này tương tự như việc nâng cấp CPU cho máy chủ, giúp cải thiện tính sẵn sàng mà không ảnh hưởng đến trải nghiệm của người dùng cuối.
Kiến trúc HA nên có một số đặc điểm sau:
- Trong suốt với hầu hết lỗi
- Cung cấp khả năng phòng ngừa từ bên trong
- Cung cấp khả năng khôi phục nhanh
- Tự động trong các hoạt động khôi phục
- Bảo vệ dữ liệu để mất mát dữ liệu là thấp nhất.
- Cung cấp các giải pháp HA để đáp ứng yêu cầu đặt ra.
Các kiến trúc nâng cao tính sẵn sàng của cơ sở dữ liệu oracle
Kiến trúc database đơn
Đây là một cơ sở dữ liệu đơn giản, hoạt động trên một máy chủ duy nhất và tích hợp đầy đủ các tính năng High Availability (HA) Kỹ thuật flashback cho phép phục hồi nhanh chóng từ lỗi của người dùng và lỗi logic Việc định nghĩa lại hoặc tổ chức lại cơ sở dữ liệu có thể giảm thiểu thời gian ngừng hoạt động trong quá trình bảo trì Công cụ sao lưu RMAN đáp ứng hiệu quả yêu cầu khôi phục hệ thống của người dùng.
Đặc điểm HA có khả năng hoạt động trong mọi kiến trúc, cho phép tạo ra một cơ sở dữ liệu đơn luôn sẵn sàng Những đặc điểm này đảm bảo tính khả dụng và độ tin cậy cao cho hệ thống.
Giảm thời gian downtime của ứng dụng và upgrade oracle
Nhân bản một bước các đối tượng đối với việc định nghĩa online nhanh hơn trong quá trình nâng cấp
■ Loại bỏ các package PL/SQL lỗi sau khi thay đổi đối với các objects
■ Điều khiển các lock DDL (data definition language - ngôn ngữ định nghĩa dữ liệu)
Có khả năng flashback để bảo vệ khỏi lỗi người dùng và gián đoạn logic.
Flashback Version Query lấy lại được cấu trúc và dữ liệu lịch sử tại một thời điểm cụ thể
Flashback Transaction Query cho phép người dùng truy xuất cấu trúc và dữ liệu lịch sử của một giao dịch cụ thể hoặc tất cả các giao dịch trong một khoảng thời gian nhất định.
■ Flashback Table khôi phục một bảng tới thời điểm trước khi bị lỗi
■ Flashback Drop khôi phục một bảng bị drop
Flashback Database là giải pháp khôi phục cơ sở dữ liệu hiệu quả, cho phép định nghĩa lại hoặc cấu hình lại trực tuyến với thời gian ngừng hoạt động tối thiểu hoặc không có, đảm bảo sự ổn định cho các thay đổi của đối tượng và ứng dụng.
Bất kỳ thuộc tính vật lý nào của bảng đều có thể được thay đổi trực tuyến Bảng có khả năng di chuyển đến vị trí khác, có thể được phân chia thành các partition và có thể chuyển đổi từ bảng này sang bảng khác.
Nhiều thuộc tính logic có thể được điều chỉnh, bao gồm tên cột, loại và kích thước Người dùng có khả năng thêm, sửa đổi, xóa hoặc gộp các cột theo nhu cầu.
■ Index thứ 2 có thể được tạo và rebuild lại trên một bảng có index Index thứ hai hỗ trợ việc sử dụng hiện quả của các block hints
■ Index có thể được tạo online hoặc analyze vào cùng một thời điểm
■ Loại dữ liệu CLOB and BLOB được hỗ trợ support.
Quản lý việc backup và recover một cách tự động.
Sao lưu và phục hồi tự động trên đĩa cung cấp một vị trí lưu trữ thống nhất cho việc sao lưu, bao gồm các tệp log và các tệp cần thiết khác cho quá trình sao lưu.
■ Có khả năng sử dụng rman để backup tăng trưởng mà không phải quét toàn bộ các file
■ Khả năng sử dụng rman để khôi phục lại database tới thời điểm bị lỗi
Tạo lại đối tượng nhanh và hiệu quả Data Pump
Thực hiện recovery nhanh trong quá trình startup
Giảm thời gian recover trong quá trình startup
Quản lý đơn giản và được tích hợp với oracle enterprise manager
Cài đặt, cấu hình qua giao diện đồ họa dễ dàng.
■ Thực hành quản lý và giám sát được tích hợp.
Kiến trúc RAC
This architecture focuses on a Real Application Clusters (RAC) database, which ensures continuous operation for both planned and unplanned activities within the cluster In the event that a node or instance goes down, the application can quickly and seamlessly failover to the remaining node or instance, maintaining uninterrupted service.
Kiến trúc "RAC only" sử dụng Real Application Cluster, mang lại hệ thống có tính sẵn sàng cao Trong môi trường RAC, cluster có khả năng cung cấp dịch vụ liên tục, đáp ứng cả các tác động có kế hoạch và không có kế hoạch Tất cả các đặc điểm có thể triển khai trên một cơ sở dữ liệu đơn đều có thể áp dụng trong môi trường RAC.
Oracle RAC không chỉ sở hữu các đặc điểm cơ bản của một cơ sở dữ liệu Oracle, mà còn tận dụng khả năng dự phòng thông qua việc gộp nhóm, giúp phân phối tính sẵn sàng ngay cả khi có một node bị lỗi trong cụm n node Người dùng vẫn có thể truy cập dữ liệu miễn là còn ít nhất một node hoạt động.
Kiến trúc này cung cấp các lợi thế sau:
• Việc failover các node và instance nhanh (có thể tính bằng giây)
• Dịch vụ, kết nối thông minh và được kết hợp failover qua nhiều instance
• Có thể chuyển qua lại các service, instance và node theo kế hoạch
• Có khả năng nâng cấp
• Nhiều instance cùng active trên nhiều node
• Tính điều khiển toàn diện được tích hợp cùng với các đặc điểm cluster và database
Kiến trúc dataguard
Site chính lưu trữ cơ sở dữ liệu chính, trong khi site thứ hai có thể chứa một hoặc nhiều cơ sở dữ liệu phụ Khi xảy ra lỗi tại site chính hoặc cơ sở dữ liệu mà không thể khắc phục nhanh chóng, chúng ta có thể sử dụng dataguard để thực hiện failover hoặc switch over sang cơ sở dữ liệu phụ.
Kiến trúc này mang đến giải pháp High Availability (HA) mạnh mẽ, đáp ứng nhu cầu của các doanh nghiệp về khôi phục lỗi Dataguard hỗ trợ hai kỹ thuật chính: redo apply và SQL apply, cho phép thiết lập hai loại cơ sở dữ liệu dự phòng: cơ sở dữ liệu standby vật lý và cơ sở dữ liệu standby logic.
Cơ sở dữ liệu physical standby cung cấp giải pháp High Availability (HA) cho hàng nghìn ứng dụng từ phiên bản Oracle 6, với sự ra mắt của Oracle Data Guard trong Oracle 8i và sự phát triển tiếp theo trong Oracle 9i và 10g, mang lại một giải pháp HA hiệu quả và đơn giản Kiến trúc physical standby Data Guard được coi là phương pháp hiệu quả nhất Trong khi đó, logical standby database, được giới thiệu trong Oracle 9i, cho phép khôi phục giao dịch đồng thời với các hoạt động đọc ghi trên cùng một cơ sở dữ liệu, mặc dù yêu cầu nhiều tiến trình xử lý hơn Cả hai loại cơ sở dữ liệu này đều có thể được sử dụng như một phần của giải pháp HA theo đề xuất trong MAA, trong đó physical standby database chủ yếu phục vụ cho việc thay đổi vai trò và xử lý lỗi, còn logical standby database được sử dụng cho báo cáo và truy vấn.
Physcial standby database cung cấp các lợi thế sau :
• Bảo vệ khỏi lỗi người dùng và hoặc những gián đoạn logic
• Bảo vệ khỏi những lỗi xảy ra đối với site hoặc thảm họa nếu được đặt ở xa
• Khôi phục lỗi nhanh (tính bằng phút)
• Dễ dàng tráo đổi vai trò phục vụ cho việc bảo trì
• Backup có thể đặt trên standby database thay vi đặt trên primary database
Logical standby database có khả năng chỉ đọc và sử dụng tài nguyên hiệu quả hơn, đồng thời mang lại nhiều lợi ích trong việc khôi phục sau sự cố và bảo vệ dữ liệu.
• Cho phép standby oracle có khả năng open đối với hoạt động thông thường với cả hai truy cập đọc ghi và chỉ đọc
• Cho phép xây dựng các object mới hoặc bảo trì
• Cho phép nâng cấp database
Khi xây dựng kiến trúc Data Guard, cần lưu ý rằng cơ sở dữ liệu standby vật lý (physical standby) và cơ sở dữ liệu standby logic (logical standby) có thể được triển khai trên cùng một cơ sở dữ liệu, nhưng nên được đặt ở vị trí cách xa cơ sở dữ liệu chính về mặt vật lý Cơ sở dữ liệu standby vật lý có thể được sử dụng cho việc failover trong trường hợp thảm họa, trong khi cơ sở dữ liệu standby logic vẫn có thể phục vụ cho việc báo cáo Ngoài ra, cơ sở dữ liệu standby vật lý cung cấp kỹ thuật áp dụng nhanh chóng, vì redo log không cần phải chuyển đổi sang dạng SQL.
Dưới đây là kiến trúc dataguard
Kiến trúc có tính sẵn sàng cao nhất (MAA)
Site chính chứa database chính hoạt động trong môi trường RAC, trong khi site phụ bao gồm một cluster với cả database phụ vật lý và database phụ logic Kiến trúc này mang đến giải pháp toàn diện cho việc quản lý sự cố không có kế hoạch và có kế hoạch, kế thừa những ưu điểm của cả kiến trúc RAC và dataguard.
RAC và Data Guard là hai thành phần chính trong giải pháp MAA, cung cấp kiến trúc toàn diện giúp giảm thiểu thời gian downtime và cải thiện khả năng phát hiện, ngăn ngừa, cũng như khôi phục lỗi Để triển khai MAA hiệu quả, cần có hai site xác định: site chính chứa cơ sở dữ liệu RAC và site thứ hai bao gồm cả physical standby database lẫn logical standby database trong môi trường RAC.
Streams
Trang chính lưu trữ cơ sở dữ liệu chính, trong khi trang thứ hai sử dụng kỹ thuật streams để đồng bộ hóa cơ sở dữ liệu Cả hai trang đều có thể hoạt động đồng thời và hỗ trợ giao dịch đồng bộ hai chiều Hệ thống hạ tầng có thể không đồng nhất.
Stream là công cụ hiệu quả cho việc chia sẻ và phân phối thông tin, cung cấp giải pháp HA cao Nó cho phép người dùng kiểm soát nội dung được đồng bộ và phương thức đồng bộ hóa Hệ thống hỗ trợ kỹ thuật đồng bộ hai chiều, truyền dữ liệu và gom nhóm con.
Stream mang lại hiệu quả tốt nếu một hoặc nhiều điều kiện sau được thỏa mãn:
• Cấu hình active/active trên cả 2 site
• Cấu hình site trên các nền tảng không đồng nhất
• Điều khiển tốt thông tin và dữ liệu chia sẻ
• Có khả năng đầu tư xây dựng một giải pháp HA
Backup và restore
Sao lưu dữ liệu là một hoạt động thiết yếu của quản trị viên hệ thống nhằm bảo vệ dữ liệu khỏi mất mát do lỗi phần cứng, phần mềm, sai sót con người, trộm cắp, virus máy tính và thảm họa tự nhiên Dù các kỹ thuật đồng bộ hóa dữ liệu ngày càng phổ biến, việc sao lưu vẫn giữ vai trò quan trọng trong bảo vệ dữ liệu và khôi phục sau thảm họa Hệ thống sao lưu cho phép phục hồi dữ liệu trong trường hợp mất mát, bất kể loại môi trường lưu trữ nào được sử dụng Các chiến thuật sao lưu như online, offline, sao lưu đầy đủ hoặc từng phần, cùng với tần suất sao lưu và lựa chọn môi trường lưu trữ, đều ảnh hưởng đến chi phí và tốc độ của quá trình này Sao lưu online cho phép truy cập dữ liệu trong khi sao lưu diễn ra, trong khi sao lưu offline yêu cầu thời gian ngừng hoạt động Backup đầy đủ sao chép toàn bộ dữ liệu, trong khi backup từng phần chỉ sao chép các thay đổi từ bản sao trước đó Tần suất sao lưu ảnh hưởng đến thời gian phục hồi (RPO), với tần suất cao giúp giảm RPO nhưng có thể ảnh hưởng đến hiệu suất hệ thống.
Hoạt động backup và restore là cần thiết để đảm bảo tính sẵn sàng của dữ liệu, nhưng thường gây giảm hiệu suất hệ thống và tăng downtime Do đó, việc thiết kế quy trình backup cần cân nhắc kỹ lưỡng để đạt được sự cân bằng giữa tính sẵn sàng, hiệu suất và downtime Thiết kế này cần được rà soát thường xuyên theo sự thay đổi của kinh doanh, kỹ thuật và khối lượng dữ liệu Đánh giá hiệu quả của tính sẵn sàng hệ thống lưu trữ là một thách thức quan trọng Mặc dù có nhiều giải pháp thương mại cho backup, quá trình này vẫn có thể làm giảm hiệu suất trong backup online hoặc gây gián đoạn trong backup offline Để giảm thời gian backup, cần lập lịch vào thời điểm hệ thống ít tải nhất hoặc lựa chọn phương pháp backup tăng trưởng Khối lượng backup là yếu tố then chốt, và kỹ thuật loại bỏ dữ liệu trùng lặp có thể giúp giảm dung lượng dữ liệu, từ đó rút ngắn thời gian backup Cần có một khung chung để phân tích tính sẵn sàng và hiệu suất hoạt động của hệ thống.
Recovery Manager (RMAN) là công cụ của ORACLE giúp quản lý việc sao lưu và khôi phục cơ sở dữ liệu RMAN xác định phương pháp thực hiện tối ưu cho các hoạt động sao lưu, khôi phục và phục hồi khi cần thiết.
RMAN cung cấp các lợi thế sau:
• Cho phép các datafile duy trì ở trạng thái online trong khi sửa chữa các lỗi block
• Đơn giản hóa hoạt động backup và recover
• Các backup có liên quan được lưu trữ
• Thực thi lại các file chưa được backup hoặc backup fail
• Cho phép restore lại file được yêu cầu
• Tối ưu hóa backup sẽ backup những file được yêu cầu backup và chưa bao giờ được backup
• Tối ưu hóa restore đưa ra phỏng đoán không cần restore datafile và archive log
• Cho phép tự động backup control file và parameter file phòng trường hợp lỗi server
• Đặc điểm report cho phép trả lời câu hỏi: database của tôi có khả năng recover hay không?
• Hỗ trợ backup nhiều kích thước block
Giám sát hệ thống
Giao thức
Có nhiều công cụ để thu thập dữ liệu từ máy chủ và thiết bị sử dụng giao thức SNMP (Simple Network Management Protocol) Hầu hết các máy tính và thiết bị mạng đều hỗ trợ truy cập SNMP Để hiểu rõ dữ liệu SNMP từ máy chủ và thiết bị, cần một công cụ đặc biệt cùng với bảng đối chiếu dữ liệu (Management Information Base – MIB) SNMP có lợi thế về yêu cầu băng thông thấp, nên thường được ứng dụng trong giám sát công nghiệp.
Nếu bản thân ứng dụng không cung cấp MIB và thông qua SNMP thì SNMP không thích hợp cho việc thu thập dữ liệu
Một số giao thức phù hợp cho các ứng dụng giám sát bao gồm CORBA, ngôn ngữ độc lập với hệ điều hành, JMX, giao thức quản lý và giám sát dành riêng cho Java, và có thể sử dụng TCP/IP hoặc UDP.
Truy cập dữ liệu
Truy cập dữ liệu tham chiếu đến giao diện cho phép các tiến trình xử lý khác sử dụng dữ liệu giám sát Chẳng hạn, khi hệ thống giám sát hoạt động như một máy chủ CORBA, client có thể thực hiện các lời gọi để theo dõi trạng thái hiện tại và lịch sử của một yếu tố nhất định.
Chế độ
Chế độ thu thập dữ liệu của giám sát hệ thống là vô cùng quan trọng Các chế độ: monitor poll, agent push, và hybrid scheme a/ Monitor poll
Trong chế độ giám sát, một hoặc nhiều tiến trình thăm dò các yếu tố hệ thống qua nhiều luồng Quá trình này lặp đi lặp lại, sử dụng các lời gọi SNMP để thăm dò thiết bị, truy cập máy chủ qua SSH/TELNET để thực thi mã, file dump, hoặc câu lệnh hệ điều hành cụ thể Ứng dụng cũng có thể thăm dò trạng thái dữ liệu hoặc ghi lại thông tin vào file.
Phương thức này có lợi thế là giảm thiểu hoạt động trên máy chủ và thiết bị được thăm dò, với CPU của máy chủ chỉ được tải trong thời gian thực hiện thăm dò Phần lớn thời gian còn lại, quá trình giám sát không tiêu tốn tài nguyên CPU, giúp tối ưu hóa hiệu suất hệ thống.
Phương thức này gặp bất lợi khi tiến trình giám sát chỉ có thể diễn ra trong khoảng thời gian đã định Nếu việc thăm dò kéo dài quá lâu, thời gian dự kiến sẽ bị kéo dài, ảnh hưởng đến hiệu quả của quá trình giám sát.
Trong chế độ giám sát đơn giản, máy chủ tự động gửi dữ liệu của mình đến ứng dụng giám sát hệ thống Quá trình này có thể diễn ra theo khoảng thời gian định sẵn hoặc theo yêu cầu từ hệ thống giám sát.
Phương thức này giúp giảm tải cho hệ thống giám sát, chỉ cần chấp nhận và lưu trữ dữ liệu mà không cần lo lắng về thời gian time-out cho các lệnh SSH hoặc kết quả khác.
Phương thức này có nhược điểm là quy trình logic cho vòng đời thăm dò không được tập trung tại hệ thống giám sát, mà được phân phối đến từng nút giám sát Do đó, bất kỳ sự thay đổi nào từ hệ thống giám sát đều cần phải được điều chỉnh tại các nút, dẫn đến sự phức tạp trong quản lý.
Chế độ trung gian giữa monitor – poll và agent – push sử dụng phương pháp phân tầng, trong đó cấu hình hệ thống xác định vị trí giám sát cho cả hệ thống và các agent Khi ứng dụng hoạt động, chúng có khả năng xác định đơn vị hệ thống nào sẽ phản hồi khi có yêu cầu thăm dò.
Hệ thống giám sát cần đảm bảo tính sẵn sàng cao, vì nếu xảy ra lỗi, mọi hệ thống được giám sát sẽ không thể thu thập thông tin hoặc cảnh báo cho quản trị viên.
Một số công cụ giám sát oracle
Oracle Enterprise Manager
Oracle Enterprise Manager, được phát triển bởi Oracle, cung cấp khả năng quản lý và giám sát toàn diện với nhiều tùy chọn thông báo khác nhau Điểm mạnh lớn nhất của nó là khả năng quản lý toàn bộ các lớp ứng dụng, từ hệ điều hành đến ứng dụng Các thành phần như cơ sở dữ liệu, máy chủ ứng dụng và phần cứng được xem như các mục tiêu (target) có thể được giám sát đồng thời hoặc nhóm lại với nhau Các loại mục tiêu khác nhau nhưng có chức năng tương tự có thể được tổ chức thành nhóm, giúp tối ưu hóa quy trình quản lý.
Mọi mục tiêu được giám sát bởi một Oracle Management Agent (OMA), có thể được cài đặt trên máy cần giám sát hoặc trên một máy khác Khi OMA được cài đặt trên một máy, nó sẽ tự động thu thập thông tin từ các mục tiêu.
Một ví dụ về oracle control homepage :
Hình 22: Giao diện oracle control homepage
Một grid control homepage sẽ monitor một số loại thông tin chính sau :
Trạng thái hoạt động hiện tại của tất cả các target được hiển thị qua biểu đồ tròn, giúp người quản trị nhanh chóng nhận diện loại target đang gặp sự cố và những target không kết nối được.
Một cái nhìn tổng quan về tình hình thực tế trong hệ thống cho thấy thông tin có thể được xác định ở cả cấp độ phần cứng và oracle Dưới đây là danh sách các liên kết hữu ích đến các tài nguyên oracle trực tuyến.
Alert được hình thành từ sự kết hợp của nhiều yếu tố và được xác định dựa trên các metric cụ thể Có bốn trạng thái cần kiểm tra cho bất kỳ metric nào: lỗi (error), cảnh báo (warning), nghiêm trọng (critical) và rõ ràng (clear) Người quản trị cần đưa ra các quyết định phù hợp dựa trên những trạng thái này.
- Object nào cần được monitor (database, nodes, listerner, hay các service khác)
- Cái gì nên được lấy mẫu
- Tần suất các sự kiện được lấy mẫu
- Phải thực hiện điều gì khi đạt đến ngưỡng đặt ra.
Một số công cụ giám sát của hãng thứ 3
TOAD (Tool for Oracle Application Developers) của Quest Software là một công cụ quản trị cơ sở dữ liệu và phát triển ứng dụng hiệu quả với chi phí vận hành thấp Công cụ này nâng cao năng suất và chất lượng sản phẩm, phục vụ người dùng ở mọi cấp độ, từ phát triển phần mềm đến quản trị cơ sở dữ liệu và phân tích kinh doanh TOAD tích hợp nhiều tính năng đáp ứng đa dạng yêu cầu và tương thích với các hệ quản trị cơ sở dữ liệu như Oracle, SQL Server, IBM DB2 và MySQL.
TOAD chạy trên tất cả các nền tảng Windows 32 bit, bao gồm Windows 95,
Để cài đặt công cụ này trên các hệ điều hành như 98, NT, 2000, XP và Vista, người dùng cần đảm bảo có khoảng 38 MB dung lượng trống trên ổ cứng và 128 MB RAM Ngoài ra, phiên bản phần mềm Oracle yêu cầu phải là 7.3.4 hoặc cao hơn.
TOAD cung cấp nhiều phiên bản khác nhau, từ cơ bản đến cao cấp, đáp ứng nhu cầu đa dạng của người dùng Các phiên bản này có thể bao gồm nhiều module bổ sung, một số được cung cấp miễn phí trong khi các phiên bản thương mại hóa đi kèm với nhiều tính năng chuyên sâu hơn.
Manage Engine là giải pháp quản lý hiệu suất máy chủ, ứng dụng và mạng, mang lại cái nhìn toàn diện về hạ tầng công nghệ thông tin của doanh nghiệp Giải pháp này cung cấp dịch vụ quản lý hiệu suất ứng dụng, theo dõi sâu về hiệu suất và tính sẵn sàng của dịch vụ mạng, cùng với khả năng giám sát băng thông và cung cấp thông tin thời gian thực về mạng.
HÌnh 24: Giao diện manage Engine
PHẦN C: XÂY DỰNG HỆ THỐNG GIÁM SÁT CẢNH BÁO CSDL ORACLE TẠI VIETTEL
Hiện trạng hoạt động hệ thống dịch vụ
Công việc của đơn vị chủ yếu là vận hành giám sát, không trực tiếp phát triển phần mềm hay dịch vụ, mà tiếp nhận và triển khai các hệ thống từ đối tác Hệ thống tiếp nhận rất đa dạng, nhưng tất cả dịch vụ đều tuân theo mô hình gồm ba thành phần chính: ứng dụng, hạ tầng mạng và cơ sở dữ liệu.
Hình 25: Mô hình dịch vụ thực tế đang chạy
Mỗi thành phần trong hệ thống đều có đội ngũ nhân viên quản trị vận hành riêng, bao gồm quản trị ứng dụng, hạ tầng mạng và cơ sở dữ liệu Nhân viên quản trị ứng dụng thực hiện các thao tác như thêm mới và cập nhật thông tin khách hàng, cũng như nâng cấp tính năng hệ thống Nhân viên quản trị hạ tầng mạng đảm bảo kết nối từ máy chủ ứng dụng đến máy chủ cơ sở dữ liệu và quản lý các địa chỉ IP, đồng thời đề xuất phương án dự phòng cho thiết bị mạng Nhân viên quản trị cơ sở dữ liệu đảm bảo an toàn dữ liệu, thực hiện sao lưu và đề xuất nâng cấp hệ thống cơ sở dữ liệu, tối ưu hóa câu lệnh Cơ sở dữ liệu được triển khai trên nhiều nền tảng hệ điều hành khác nhau như Linux, Unix và Windows, với các hệ quản trị dữ liệu đa dạng như Oracle, Oracle TimesTen, DB2, MySQL Server và SQL Server.
Bất cập trong vấn đề giám sát vận hành
Hệ thống có số lượng lớn với nhiều database, mỗi database lại được hỗ trợ bởi nhiều server Mỗi dịch vụ thường yêu cầu ít nhất một database, nhưng tùy thuộc vào thiết kế và quy mô hệ thống, có thể có vài database, trong đó một số database có dung lượng lên tới vài terabyte.
Các hệ thống thường được đối tác giám sát bằng công cụ riêng, nhưng khi chuyển giao, phần giám sát không được chuyển giao, chỉ có liên quan đến ứng dụng, trong khi đó, thông tin về cơ sở dữ liệu hầu như không có.
- Số lượng database lớn, nhưng số lượng người quản trị database lại ít, mỗi người phải đảm nhận nhiều database một lúc
- Các công cụ dùng để monitor database thường thì dùng trực tiếp khi người quản trị online.
Các công cụ monitor database thường được sử dụng
Đội ngũ chuyên gia dày dạn kinh nghiệm của chúng tôi đã phát triển một hệ thống database được sử dụng rộng rãi trên toàn cầu, mang đến nhiều tính năng hữu ích và dễ sử dụng.
- Có giao diện đồ họa nên trực quan, sinh động
- Có khả năng giám sát, monitor nhiều loại database
- Tương thích với nhiều nền tảng hệ điều hành
- Tuy nhiên, khả năng bổ sung chức năng giám sát còn hạn chế, không can thiệp được sâu vào phần mềm
- Không thể thực hiện lấy báo cáo trong một thời gian dài, cũng như kiểm tra lịch sử giám sát của database
Hình 26: Giao diện giám sát Manage Engine
Xây dựng công cụ giám sát, cảnh báo riêng
Mô hình chung
Hình 27: Mô hình giám sát chung
Dữ liệu là yếu tố then chốt trong hệ thống giám sát, với chất lượng, độ tin cậy, tính sẵn có và sự phù hợp của dữ liệu đóng vai trò quyết định cho sự thành công của giải pháp Các mô hình đơn giản có thể đạt hiệu quả cao nếu được xử lý dữ liệu tốt, cung cấp thông tin giá trị Ngược lại, một mô hình phức tạp với giải pháp tốt nhưng dữ liệu không rõ ràng sẽ không mang lại hiệu quả như mong đợi.
Quá trình giám sát bắt đầu bằng việc thu thập và phân tích dữ liệu, tiếp theo là bước tiền xử lý dữ liệu Sau khi dữ liệu được xử lý, kết quả thu được sẽ được sử dụng làm đầu vào cho bước hậu xử lý, nơi mà kết quả sẽ được chuyển đổi thành dạng dễ hiểu cho yêu cầu bài toán Dưới đây, chúng ta sẽ đi sâu vào từng bước trong quy trình xử lý dữ liệu, bắt đầu từ việc thu thập dữ liệu.
Bước thu thập dữ liệu gồm 3 nhiệm vụ chính:
Khi lập kế hoạch thu thập dữ liệu, bước đầu tiên là xác định các yêu cầu dữ liệu cần thiết để giải quyết vấn đề Điều này có thể cần sự hỗ trợ từ các chuyên gia trong lĩnh vực liên quan Cần phải xác định rõ các dữ liệu chắc chắn liên quan, các dữ liệu có thể liên quan, và dữ liệu phụ trợ Những dữ liệu chắc chắn hoặc có khả năng liên quan sẽ được xem là đầu vào cho hệ thống.
• Xác định nguồn dữ liệu
Bước tiếp theo là xác định nguồn dữ liệu, điều này giúp chúng ta hiểu rõ hơn về những khó khăn trong quá trình thu thập Chúng ta cần chú ý đến độ chính xác và khả năng trình bày của dữ liệu cho từng trường hợp cụ thể.
• Xác định lượng dữ liệu
Sau khi thu thập dữ liệu thô, cần chuyển đổi chúng thành các định dạng phù hợp để chuẩn bị cho quá trình xử lý dữ liệu Ở bước này, cần thực hiện một số công việc quan trọng.
• Kiểm tra tính hợp lệ của dữ liệu
Kiểm tra tính hợp lệ là cần thiết để phát hiện các dữ liệu không hợp lệ liên quan đến phần trăm sử dụng của các mount point Nếu dữ liệu chỉ trỏ về tên các mount point mà không có thông tin về mức sử dụng, thì điều này là không chấp nhận được.
Để xử lý mẫu có kết quả sai, cần xem xét nguyên nhân gây ra sai lầm Tùy thuộc vào bản chất của nguyên nhân, chúng ta có thể loại bỏ dữ liệu không chính xác, điều chỉnh phương pháp lấy mẫu cho phù hợp, hoặc chấp nhận những thiếu sót đó Nếu có yếu tố dẫn đến quyết định sai lầm, cần phải loại bỏ ngay lập
Phân hoạch dữ liệu là quá trình tổ chức dữ liệu thành các nhóm riêng biệt để giám sát và cảnh báo từng thuộc tính cụ thể Điều quan trọng là đảm bảo rằng các thuộc tính khác nhau không bị trùng lặp hoặc nhầm lẫn thông tin Để đạt được điều này, cần thực hiện một số công việc nhất định.
1) Chuyển đổi dữ liệu về khuôn dạng phù hợp với đầu vào của tiến trình xử lý Điều này làm đơn giản hóa quá trình xử lý dữ liệu
2) Lựa chọn dữ liệu xác đáng nhất Điều này, thật sự cần thiết khi dữ liệu mang các thông tin thừa
3) Tối thiểu hóa tham số đầu vào Điều này được thực hiện làm đơn giản hóa bài toán b/ Xử lý dữ liệu
Sau khi đã có dữ liệu đầu vào, bước tiếp theo là tiến hành xử lý dữ liệu Cần xây dựng các hàm, gói và ngưỡng cho từng nhóm dữ liệu Tiến hành so sánh, đối chiếu và tính toán để đưa ra kết quả cuối cùng và thông báo Cuối cùng là thực hiện hậu xử lý dữ liệu.
Hậu xử lý dữ liệu là quá trình thực hiện các thao tác nhằm chuẩn bị đầu ra dữ liệu, phụ thuộc vào loại dữ liệu và đối tượng mục tiêu Các thao tác này tuân theo quy tắc đã được thống nhất trước đó và thường phục vụ cho mục đích báo cáo và tổng hợp thông tin.
Chương trình cảnh báo, giám sát
Chương trình được phát triển dựa trên các lý thuyết đã nêu, với việc xác định các thuộc tính cần thu thập thông tin dữ liệu là rất quan trọng Trong quá trình thực hiện, nhiều bài toán xuất hiện cần được giải quyết, ví dụ như việc đưa ra các bài toán cụ thể để xử lý.
- Giám sát, cảnh báo backup log rman
Để nâng cao tính sẵn sàng cho cơ sở dữ liệu, việc giám sát và cảnh báo tiến trình đồng bộ Data Guard là rất quan trọng Một trong những phương pháp phổ biến và đơn giản nhất để bảo vệ dữ liệu là tạo bản sao lưu hoặc đồng bộ hóa với một cơ sở dữ liệu phụ Chúng ta cần thiết lập quy trình kiểm tra và giám sát các tiến trình sao lưu, đặc biệt là việc giám sát và cảnh báo backup log RMAN để đảm bảo rằng mọi hoạt động sao lưu diễn ra suôn sẻ và kịp thời.
The input data consists of backup log files from the RMAN backup process We need to verify and cross-check the data, which is formatted as follows: "bash 2.05$ more rman_backup_rw_full_inter20_3_27_20130301.log-".
Recovery Manager: Release 10.2.0.5.0 Production on Fri Mar 1 18:15:02 -
Copyright (c) 1982, 2007, Oracle All rights reserved connected to target database: INTER20 (DBID 53298097)
Here is the rewritten paragraph:When using the target database control file instead of a recovery catalog, RMAN allocates multiple channels for backup and recovery operations, including ORA_DISK_1, ORA_DISK_2, ORA_DISK_3, and ORA_DISK_4 During the crosscheck process, RMAN identifies several backup pieces as 'EXPIRED', including those with handles such as /backup_rw1/backup_full/inter20_3_27_data_f805069526_s75959_s1, /backup_rw1/backup_full/inter20_3_27_data_f805069526_s75960_s2, and /backup_rw1/backup_full/inter20_3_27_data_f805074359_s75966_s2, among others, with corresponding recid and stamp values.
Quá trình sao lưu cung cấp hai thông tin quan trọng: trạng thái hoàn thành của việc sao lưu và mức độ thành công của nó Dựa trên những thông tin này, chúng ta có thể phân loại dữ liệu thành các trường thông tin cụ thể.
IP: ip mà database đang sử dụng
Log_Warning: thông tin warning trong quá trình thực hiện backup.
Log_error: thông tin lỗi trong quá trình thực hiện backup
Create_date: thời gian thực hiện quá trình check thông tin.
Dữ liệu này có thể được lưu vào bảng tổng hợp, ví dụ như sau:
ERROR WARNING CREATE_DATE DB_IP
Bảng 2 Bảng tổng hợp backup log:
'select ERROR,WARNING from backup_log where db_ip=''' || v_ip
|| ''' and CREATE_DATE in (select max(CREATE_DATE ) from backup_log where db_ip='''
Sử dụng một control để quét bảng, nếu thấy tồn tại thông tin về backup lỗi, hay có cảnh báo thì đưa ra thông báo.
Hậu xử lý dữ liệu:
Khi phát hiện lỗi trong quá trình sao lưu, cần thông báo ngay để người quản trị cơ sở dữ liệu kiểm tra nguyên nhân và thực hiện sao lưu lại Đồng thời, việc giám sát và cảnh báo tiến trình đồng bộ của Dataguard cũng rất quan trọng để đảm bảo hệ thống hoạt động ổn định.
Dataguard là giải pháp đồng bộ hóa hoàn toàn giữa hai cơ sở dữ liệu, cho phép chuyển dữ liệu từ một site này sang một site khác Ví dụ, người dùng có thể đồng bộ hóa cơ sở dữ liệu tại Hà Nội với cơ sở dữ liệu tại Huế thông qua Dataguard.
Database được đồng bộ không ở trạng thái mở, khiến các công cụ giám sát thông thường không thể sử dụng tài khoản thông thường để theo dõi hoạt động của nó Điều này đặt ra một thách thức: làm thế nào để xác định tiến trình đồng bộ giữa hai database đang hoạt động hiệu quả hay gặp lỗi.
Thu thập thông tin và tiền xử lý dữ liệu
Quá trình hoạt động của Data Guard liên quan đến việc đọc các file archive log trên cơ sở dữ liệu chính, chứa thông tin về sự thay đổi của cơ sở dữ liệu, và sau đó cập nhật những thay đổi này vào cơ sở dữ liệu phụ Do đó, dữ liệu đầu vào cần phải liên quan đến các file archive log, mặc dù các file này được lưu dưới dạng nhị phân và không thể xem trực tiếp.
Trong Oracle, view v$archived_log cho phép kiểm tra tiến trình hoạt động của Data Guard Để tránh dư thừa dữ liệu, chúng ta chỉ cần xác định hai thông tin quan trọng: liệu các archive đã được chuyển từ database chính sang database phụ và liệu chúng đã được cập nhật vào database phụ hay chưa Dựa vào những thông tin này, ta có thể tổng hợp được các dữ liệu cần thiết.
IP database chính: database đang chạy thật
IP database phụ: database dùng để nhận đồng bộ.
Trạng thái đồng bộ:Trạng thái có đồng bộ hay không.
Dữ liệu này có thể lưu vào một bảng tổng hợp như sau:
SEVERITY PRI_IP STD_IP SID SUBSTRACT STATUS CREATE_DATE
Bảng 3: Bảng tổng hợp dataguard
Hậu xử lý dữ liệu:
Dữ liệu này có thể được sử dụng để cảnh báo và lập báo cáo hàng ngày, xuất ra dưới dạng file Excel để gửi cho người quản trị Nhờ đó, người quản trị có thể chủ động kiểm tra và có biện pháp xử lý đối với tiến trình đồng bộ giữa hai cơ sở dữ liệu.
Tính tùy biến và mở rộng của hệ thống giám sát
Hệ thống giám sát được xây dựng bằng các shell script mang lại tính linh hoạt cao, với mỗi script đảm nhiệm một chức năng riêng Việc thêm mới hoặc loại bỏ script rất dễ dàng, và khi phát hiện lỗi, có thể nhanh chóng thêm đoạn script kiểm tra để giảm thiểu khả năng tái diễn lỗi Quá trình triển khai các script này cũng diễn ra một cách thuận tiện.
Chúng ta có thể dễ dàng thêm, giám sát hoặc loại bỏ một database mà không ảnh hưởng đến hoạt động của nó Hệ thống cho phép tùy chỉnh thời gian gửi tin nhắn cảnh báo, với các khoảng thời gian linh hoạt từ 5 đến 20 phút Điều này giúp nâng cao tinh thần trách nhiệm của nhân viên quản trị hệ thống mà không cần phải giám sát họ liên tục Khác với các công cụ monitor thông thường chỉ theo dõi các database riêng lẻ và các vấn đề cơ bản, hệ thống giám sát hiện tại cho phép theo dõi các nghiệp vụ giữa các database một cách hiệu quả hơn Ngoài ra, khi phát hiện tính năng mới cần giám sát, hệ thống này cũng vượt trội hơn so với các công cụ giám sát có sẵn.
Việc cài đặt các công cụ giám sát như Manage Engine và Nagios phụ thuộc vào tính tương thích giữa phiên bản phần mềm và hệ thống Khi số lượng giám sát tăng cao, các công cụ này có thể bị quá tải, dẫn đến tình trạng treo hệ thống và không thể thống kê thông tin Hệ thống được xây dựng chủ yếu dựa trên các đoạn script, không nặng về đồ họa và tương tác giữa các lớp ứng dụng, do đó không ảnh hưởng đến hiệu suất của hệ thống.
Hệ thống này cho phép thực hiện việc thống kê, tổng hợp và rà soát báo cáo theo chu kỳ một cách dễ dàng Dữ liệu tra cứu có thể được lưu trữ trong 1 đến 2 năm, giúp chúng ta theo dõi sự phát triển và quá trình hoạt động của hệ thống trong thời gian dài.
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
Hình 28: Mô hình triển khai công cụ giám sát
Các kết quả đạt được
Giám sát hoạt động của cơ sở dữ liệu Oracle bao gồm việc theo dõi các thuộc tính như trạng thái của instance (đang hoạt động hay ngừng hoạt động), hiệu suất của máy chủ cơ sở dữ liệu thông qua số lượng session đang hoạt động và không hoạt động, cũng như các thông tin liên quan đến lỗi và cảnh báo mà hệ thống tự phát sinh.
Giám sát sự tăng trưởng dữ liệu của hệ thống theo tháng và quý giúp đưa ra các chính sách hiệu quả về việc quay vòng dữ liệu.
Giám sát hoạt động backup dự phòng giúp theo dõi hiệu quả của các mô hình có tính dự phòng cao, đồng thời kiểm tra thành công hoặc lỗi trong quá trình đồng bộ dữ liệu.
- Cảnh báo các thông tin đến cho người quản trị
Tính sẵn sàng cao là yếu tố quan trọng đảm bảo thành công trong kinh doanh, phụ thuộc vào phần cứng, phần mềm và đường truyền mạng Đây không chỉ là thuộc tính của hệ thống mà là tổng hòa của nhiều yếu tố, là mục tiêu mà mọi doanh nghiệp hướng tới Để nâng cao tính sẵn sàng, doanh nghiệp cần cải thiện độ ổn định và độ tin cậy của các thành phần như dịch vụ, phần cứng, phần mềm và đường truyền mạng.
Cơ sở dữ liệu đóng vai trò quan trọng trong các dịch vụ hiện nay, với nhiều kiến trúc và biện pháp kỹ thuật nhằm nâng cao tính sẵn sàng của dữ liệu Các kiến trúc như Data Guard, RAC và Stream, cùng với các kỹ thuật như backup, sao lưu và đồng bộ, đang được áp dụng rộng rãi Lựa chọn mô hình kiến trúc phù hợp phụ thuộc vào mức độ ảnh hưởng của dịch vụ và nhu cầu cụ thể của doanh nghiệp.
Để nâng cao tính sẵn sàng của hệ thống, giám sát hiệu quả là một phương pháp quan trọng Nhiều công cụ giám sát như Manage Engine và Nagios được sử dụng phổ biến, nhưng không có công cụ nào phù hợp hoàn hảo cho tất cả doanh nghiệp Mỗi doanh nghiệp cần lựa chọn công cụ giám sát dựa trên điều kiện dịch vụ, nhu cầu và nguồn vốn của mình.
Xây dựng một công cụ giám sát tùy chỉnh cho doanh nghiệp mang lại lợi thế cạnh tranh đáng kể Công cụ này không chỉ kế thừa những ưu điểm từ các giải pháp hiện có mà còn khắc phục những nhược điểm chỉ có thể nhận thấy khi áp dụng vào thực tế Việc phát triển công cụ giám sát tại trung tâm công nghệ thông tin vẫn đang trong quá trình hoàn thiện, dựa trên nhu cầu giám sát thực tế của hệ thống Hiện tại, Viettel đang mở rộng ra thị trường quốc tế, và việc triển khai công cụ giám sát này vẫn là một thách thức lớn.