Tôi thấy rằng khi mọi người đang thiết kế kiến trúc Oracle RAC, họ thường không nghĩ đến N + 1 dự phòng trong kế hoạch triển khai của họ. Có hai lý do để triển khai Oracle RAC, đó là tính khả dụng và khả năng mở rộng. Đối với mục đích của cuộc thảo luận này, tôi chỉ tập trung vào khía cạnh sẵn có. Nếu việc triển khai RAC của bạn chỉ vì lý do khả năng mở rộng, thì chủ đề này có thể không áp dụng cho bạn.
Vậy N + 1 Redundancy là gì? Nói một cách đơn giản, nếu bạn cần N đơn vị của một thứ gì đó, thì với mục đích dự phòng, bạn nên có N + 1 của mặt hàng đó. Hãy xem xét một máy chủ cơ sở dữ liệu. Nó phải có một nguồn cung cấp điện. Đó là một yêu cầu. Nếu không có nguồn điện hoạt động, máy chủ sẽ không hoạt động. Số bộ cấp nguồn tối thiểu là 1. Nếu chúng tôi muốn máy chủ này có mức độ sẵn sàng cao, chúng tôi sẽ đảm bảo nó có N + 1 bộ cấp nguồn, hoặc trong trường hợp này là bộ cấp nguồn kép. Nếu chỉ có một nguồn cung cấp điện và nó bị lỗi, máy chủ sẽ sử dụng nó. Nếu chúng ta có thêm một nguồn điện, một thiết bị dự phòng, thì việc mất một nguồn điện sẽ không làm hỏng máy chủ cùng với nó. Dự phòng là điều tuyệt vời cần có và là thành phần thiết yếu của cơ sở hạ tầng có tính khả dụng cao.
Khi thiết kế hệ thống Oracle RAC, DBA cần xác định số lượng nút cần thiết để hỗ trợ nhu cầu của người dùng cuối. Nếu DBA xác định 4 nút là cần thiết và cụm RAC này phải thể hiện các đặc điểm sẵn có cao, thì điều quan trọng là DBA phải tạo một cụm 5 nút (4 + 1). Nếu nhu cầu tài nguyên đủ để giữ cho 4 nút bận và một nút bị mất, 3 nút còn lại sẽ không thể theo kịp khối lượng công việc. Nếu DBA xây dựng hệ thống RAC với khả năng N + 1, thì việc mất một nút sẽ không được người dùng cuối chú ý. Nếu DBA xây dựng cụm RAC mà không có N + 1 dự phòng, thì việc mất một nút có thể rất khủng khiếp đối với hiệu suất của người dùng cuối, đến mức toàn bộ cụm cũng có thể ngừng hoạt động. Khi thiết kế triển khai RAC của bạn, hãy cố gắng dự phòng N + 1.
Tôi nhớ hai năm trước, tôi có một cụm RAC bị mất một nút. Không sao, chúng tôi vẫn có sẵn hai nút. Khi tôi xem hiệu suất của hai nút còn lại, chúng dường như khá choáng ngợp. Trung tâm cuộc gọi của chúng tôi bắt đầu nhận được khiếu nại. Tôi đã làm việc với các quản trị viên khác trong nhóm CNTT để sao lưu và chạy nút đó nhanh nhất có thể, nhưng điều này không phải lúc nào cũng đúng nếu lý do ngừng hoạt động liên quan đến phần cứng và các bộ phận cần được thay thế. Sau khi nút hoạt động trở lại, tôi đã theo dõi hiệu suất của cụm trong nhiều tuần sau đó. Việc sử dụng của chúng tôi đã tăng lên kể từ khi hệ thống này được thiết kế ban đầu. Ban đầu chúng tôi đã thiết kế hệ thống này với N + 1 dự phòng, nhưng việc sử dụng của chúng tôi đã tăng lên và N tăng từ 2 lên 3. Cụm 3 nút hiện tại của chúng tôi không còn là N + 1 dư thừa nữa. Vì vậy, tôi đã làm việc với ban quản lý để đưa vào ngân sách của năm tới đủ tiền để mua một nút mới và đảm bảo rằng Oracle đã được cấp phép trên đó. Tôi ngủ ngon hơn nhiều vào ban đêm khi biết rằng tôi đã trở lại trạng thái dư thừa N + 1.
Giống như nhiều triển khai khác, hệ thống RAC của tôi không phải là tính năng Khả dụng cao duy nhất được tích hợp trong cơ sở hạ tầng của chúng tôi. Cơ sở dữ liệu RAC này là cơ sở dữ liệu chính cho cơ sở dữ liệu dự phòng vật lý với Oracle’s Data Guard. Tôi thực sự ngạc nhiên khi thảo luận về cơ sở dữ liệu dự phòng RAC với các DBA khác của Oracle là bao nhiêu người trong số họ không nghĩ đến khả năng N + 1 cho chế độ chờ của họ. Cơ sở dữ liệu dự phòng vật lý là mạng lưới an toàn của tôi trong trường hợp trung tâm dữ liệu chính không khả dụng vì lý do nào đó. Tôi đã thấy rất nhiều Oracle DBA triển khai chế độ chờ phiên bản duy nhất cho RAC chính nhiều nút. Ầm ầm! Tôi hy vọng họ không bao giờ phải thất bại. Toàn bộ khối lượng công việc của cụm RAC nhiều nút của họ sẽ phải vật lộn rất nhiều ở chế độ chờ phiên bản duy nhất đó. Vì vậy, khi bạn đang thiết kế triển khai RAC của mình cho cả thiết bị chính và dự phòng, hãy xem xét các tác động dự phòng N + 1 của bạn đối với thiết kế kiến trúc.
Điểm mà tôi có lẽ khác với nhiều người là việc triển khai chế độ chờ vật lý của tôi không có khả năng N + 1, mà đúng hơn là N. Tôi bỏ qua nút bổ sung dự phòng cho chế độ chờ vật lý của mình. Tại sao vậy? Hoàn toàn từ góc độ chi phí. Chế độ chờ vật lý của tôi chỉ là một mạng lưới an toàn. Tôi muốn nó hoạt động cho tôi vào ngày mà tôi cần nó. Nhưng tôi hy vọng không bao giờ cần nó. Dự phòng vật lý là chính sách bảo hiểm của tôi trong trường hợp rủi ro trở thành hiện thực. Đối với tôi, “+1” bổ sung đó tại trang web chờ là bảo hiểm quá mức. Tôi có thể tiết kiệm trên phần cứng vật lý và giấy phép Oracle.
Vì vậy, giả sử một ngày đến và tôi thực hiện chuyển đổi dự phòng sang chế độ chờ. Tôi đã mất N + 1 dự phòng. Nhưng khả năng tôi mất trung tâm dữ liệu chính * và * mất một trong các nút trong cụm dự phòng của mình là gì? Cơ hội khá mỏng. Khả năng xảy ra lỗi ở hai trang web cùng một lúc là khá nhỏ. Tại thời điểm này, nhóm CNTT của chúng tôi đang đánh giá lý do tại sao trung tâm dữ liệu chính của chúng tôi bị mất và khi nào chúng tôi có thể đưa hoạt động trở lại cơ sở đó. Nếu trung tâm dữ liệu chính bị mất toàn bộ điện năng và công ty tiện ích cho biết dịch vụ sẽ được khôi phục vào ngày mai, thì chúng tôi sẽ chỉ chạy ở trung tâm dữ liệu dự phòng mặc dù chúng tôi chỉ có N nút cho cơ sở dữ liệu RAC ở đó. Tuy nhiên, nếu trung tâm dữ liệu chính bị hỏa hoạn xóa sổ, nó sẽ mất nhiều tháng trước khi nó hoạt động trở lại. Tại thời điểm này, tôi cần phải lập kế hoạch để có được chế độ chờ vật lý lên đến N + 1 dự phòng vì thời gian sử dụng chế độ chờ đó làm chế độ chính sẽ lâu hơn nhiều. Vì vậy, chúng tôi gấp rút đặt hàng một máy chủ khác và thêm nó vào cụm càng sớm càng tốt. Vì vậy, tôi thiết kế cơ sở dữ liệu RAC ở chế độ chờ của mình là N, không phải N + 1 với mục tiêu tăng nó lên N + 1 trong thời gian ngắn nếu chúng tôi xác định rằng chúng tôi sẽ sử dụng chế độ chờ thực trong một khoảng thời gian dài hơn.
Vì vậy, có một trường hợp đặc biệt khác mà tôi muốn thảo luận. Đó là nơi DBA xác định rằng N =1. Đối với các yêu cầu khối lượng công việc hiện tại, một nút là đủ. Nhưng chúng tôi muốn có tính khả dụng cao nên chúng tôi thiết kế một cụm RAC hai nút cho cơ sở dữ liệu chính. Bây giờ chúng tôi có N + 1 dự phòng được tích hợp vào sơ cấp. Tiếp theo đoạn cuối cùng của tôi, cơ sở dữ liệu dự phòng của tôi chỉ cần 1 nút. Sai lầm mà tôi thấy một số người mắc phải là tạo chế độ chờ như một cơ sở dữ liệu đơn lẻ. Cho đến nay, logic của họ có lý. Giá trị chính là N + 1 và chế độ chờ là N. Cho đến nay vẫn tốt. Điểm khác biệt của tôi là tôi đặt chế độ chờ thành một cụm RAC một nút, không phải là một triển khai đơn lẻ thuần túy. Lý do là vì sự tăng trưởng trong tương lai. Tại một số điểm, DBA có thể thấy rằng N không còn bằng 1 ở điểm chính. Việc sử dụng đã tăng lên và N cần phải là 2 ngay bây giờ. DBA muốn phát triển nút chính thành 3 nút (2 + 1). Điều này dễ dàng thực hiện mà không có thời gian chết để thêm một nút mới vào cụm và mở rộng cơ sở dữ liệu RAC cho nút mới đó. Nhưng nó không dễ dàng thực hiện ở chế độ chờ để biến chế độ chờ thành một cụm 2 nút nếu 1 nút tồn tại đó không được kích hoạt RAC. Nếu tất cả những gì tồn tại ở chế độ chờ đơn phiên bản thuần túy, thì DBA cần loại bỏ nó và chuyển nó đến một cụm hai nút. Nếu DBA có tầm nhìn xa và cài đặt Cơ sở hạ tầng lưới như thể chế độ chờ vật lý là một cụm nút đơn, thì tất cả những gì DBA phải làm là thêm một nút mới, giống như họ đã làm ở phía chính.
Khi bạn đang thiết kế triển khai RAC của mình, hãy cân nhắc đảm bảo bạn có N + 1 khả năng ở chế độ chính và ít nhất N ở chế độ chờ. Nếu một công ty xác định rằng chế độ chờ là quá nghiêm trọng, họ cũng có thể muốn triển khai N + 1 ở chế độ chờ. Nếu DBA xác định rằng N =1, hãy cân nhắc đặt chế độ chờ ít nhất một cụm RAC nút duy nhất.
