Một số lượng đáng kể các ứng dụng Doanh nghiệp và hệ thống ảo hóa có cơ chế riêng để xây dựng các giải pháp có khả năng chịu lỗi. Cụ thể, Oracle RAC (Oracle Real Application Cluster) là một cụm gồm hai hoặc nhiều máy chủ cơ sở dữ liệu Oracle hoạt động cùng nhau để cân bằng tải và cung cấp khả năng chịu lỗi ở cấp độ máy chủ/ứng dụng. Để hoạt động ở chế độ này, bạn cần có bộ nhớ dùng chung, thường là hệ thống lưu trữ.
Như chúng ta đã thảo luận ở một trong những , bản thân hệ thống lưu trữ dù có sự hiện diện của các thành phần trùng lặp (bao gồm cả bộ điều khiển) vẫn có những điểm bị lỗi - chủ yếu ở dạng một bộ dữ liệu duy nhất. Do đó, để xây dựng một giải pháp Oracle với yêu cầu về độ tin cậy ngày càng cao, sơ đồ “N máy chủ - một hệ thống lưu trữ” cần phải phức tạp.
Tất nhiên, trước tiên, chúng ta cần quyết định những rủi ro mà chúng ta đang cố gắng bảo hiểm để chống lại. Trong bài viết này, chúng tôi sẽ không xem xét việc bảo vệ khỏi các mối đe dọa như “thiên thạch đã đến”. Vì vậy việc xây dựng giải pháp khắc phục thảm họa phân tán về mặt địa lý sẽ vẫn là chủ đề cho một trong những bài viết sau. Ở đây chúng ta sẽ xem xét cái gọi là giải pháp khắc phục thảm họa Cross-Rack, khi tính năng bảo vệ được xây dựng ở cấp độ tủ máy chủ. Bản thân các tủ có thể được đặt trong cùng một phòng hoặc ở các phòng khác nhau, nhưng thường trong cùng một tòa nhà.
Các tủ này phải chứa toàn bộ bộ thiết bị và phần mềm cần thiết cho phép vận hành cơ sở dữ liệu Oracle bất kể trạng thái của “hàng xóm”. Nói cách khác, bằng cách sử dụng giải pháp khắc phục thảm họa Cross-Rack, chúng tôi loại bỏ các rủi ro thất bại:
- Máy chủ ứng dụng Oracle
- Hệ thống lưu trữ
- Hệ thống chuyển mạch
- Hư hỏng toàn bộ thiết bị trong tủ:
- Từ chối quyền lực
- Lỗi hệ thống làm mát
- Các yếu tố bên ngoài (con người, thiên nhiên, v.v.)
Việc sao chép các máy chủ Oracle ngụ ý nguyên tắc hoạt động của Oracle RAC và được triển khai thông qua một ứng dụng. Sự trùng lặp của các cơ sở chuyển mạch cũng không phải là một vấn đề. Nhưng với sự sao chép của hệ thống lưu trữ, mọi thứ không đơn giản như vậy.
Tùy chọn đơn giản nhất là sao chép dữ liệu từ hệ thống lưu trữ chính sang hệ thống lưu trữ dự phòng. Đồng bộ hoặc không đồng bộ, tùy thuộc vào khả năng của hệ thống lưu trữ. Với việc sao chép không đồng bộ, câu hỏi đặt ra ngay lập tức là đảm bảo tính nhất quán của dữ liệu liên quan đến Oracle. Nhưng ngay cả khi có sự tích hợp phần mềm với ứng dụng, trong mọi trường hợp, trong trường hợp xảy ra lỗi trên hệ thống lưu trữ chính, sẽ cần có sự can thiệp thủ công của quản trị viên để chuyển cụm sang bộ lưu trữ dự phòng.
Một tùy chọn phức tạp hơn là “bộ ảo hóa” lưu trữ phần mềm và/hoặc phần cứng sẽ loại bỏ các vấn đề về tính nhất quán và sự can thiệp thủ công. Nhưng sự phức tạp của việc triển khai và quản lý sau đó, cũng như chi phí rất cao của các giải pháp như vậy, khiến nhiều người sợ hãi.
Giải pháp mảng Flash toàn bộ AccelStor NeoSapphire™ hoàn hảo cho các tình huống như khắc phục thảm họa Cross-Rack sử dụng kiến trúc Shared-Nothing. Mô hình này là hệ thống lưu trữ hai nút sử dụng công nghệ FlexiRemap® độc quyền để hoạt động với ổ đĩa flash. Nhờ vào NeoSapphire™ H710 có khả năng mang lại hiệu suất lên tới 600K IOPS@4K ghi ngẫu nhiên và đọc ngẫu nhiên 1M+ IOPS@4K, điều này không thể đạt được khi sử dụng các hệ thống lưu trữ dựa trên RAID cổ điển.
Nhưng tính năng chính của NeoSapphire™ H710 là thực thi hai nút dưới dạng các trường hợp riêng biệt, mỗi nút có bản sao dữ liệu riêng. Việc đồng bộ hóa các nút được thực hiện thông qua giao diện InfiniBand bên ngoài. Nhờ kiến trúc này, có thể phân phối các nút đến các vị trí khác nhau ở khoảng cách lên tới 100m, từ đó cung cấp giải pháp khắc phục thảm họa Cross-Rack. Cả hai nút hoạt động hoàn toàn đồng bộ. Nhìn từ phía máy chủ, H710 trông giống như một hệ thống lưu trữ bộ điều khiển kép thông thường. Do đó, không cần thực hiện bất kỳ tùy chọn phần mềm hoặc phần cứng bổ sung nào hoặc các cài đặt đặc biệt phức tạp.
Nếu chúng ta so sánh tất cả các giải pháp khắc phục thảm họa Cross-Rack được mô tả ở trên, thì tùy chọn từ AccelStor nổi bật hơn hẳn so với các giải pháp còn lại:
Kiến trúc không chia sẻ của AccelStor NeoSapphire™
Hệ thống lưu trữ “ảo hóa” phần mềm hoặc phần cứng
Giải pháp dựa trên bản sao
Sẵn có
Lỗi máy chủ
Không có thời gian ngừng hoạt động
Không có thời gian ngừng hoạt động
Không có thời gian ngừng hoạt động
Lỗi chuyển đổi
Không có thời gian ngừng hoạt động
Không có thời gian ngừng hoạt động
Không có thời gian ngừng hoạt động
Lỗi hệ thống lưu trữ
Không có thời gian ngừng hoạt động
Không có thời gian ngừng hoạt động
Thời gian chết
Lỗi toàn bộ tủ
Không có thời gian ngừng hoạt động
Không có thời gian ngừng hoạt động
Thời gian chết
Chi phí và độ phức tạp
Chi phí giải pháp
Thấp*
Cao
Cao
Độ phức tạp triển khai
Низкая
Cao
Cao
*AccelStor NeoSapphire™ vẫn là mảng All Flash, theo định nghĩa thì không tốn “3 kopecks”, đặc biệt vì nó có dung lượng dự trữ gấp đôi. Tuy nhiên, khi so sánh chi phí cuối cùng của giải pháp dựa trên giải pháp đó với giải pháp tương tự từ các nhà cung cấp khác, chi phí có thể được coi là thấp.
Cấu trúc liên kết để kết nối máy chủ ứng dụng và tất cả các nút mảng Flash sẽ trông như thế này:
Khi lập kế hoạch cấu trúc liên kết, chúng tôi cũng khuyên bạn nên sao chép các thiết bị chuyển mạch quản lý và kết nối các máy chủ.
Ở đây và xa hơn nữa chúng ta sẽ nói về việc kết nối qua Kênh sợi quang. Nếu bạn sử dụng iSCSI, mọi thứ sẽ giống nhau, được điều chỉnh cho các loại công tắc được sử dụng và cài đặt mảng hơi khác nhau.
Công việc chuẩn bị trên mảng
Thiết bị và phần mềm được sử dụng
Thông số kỹ thuật máy chủ và chuyển mạch
Thành phần
Описание
Máy chủ cơ sở dữ liệu Oracle 11g
Hai
Hệ điều hành máy chủ
Oracle Linux
Phiên bản cơ sở dữ liệu Oracle
11g (RAC)
Bộ xử lý trên mỗi máy chủ
Hai CPU Intel® Xeon® E16-5 v2667 2 lõi @ 3.30GHz
Bộ nhớ vật lý trên mỗi máy chủ
128GB
Mạng lưới FC
FC 16Gb/s với đa đường
FC HBA
Emulex Lpe-16002B
Cổng 1GbE công cộng chuyên dụng để quản lý cụm
Bộ chuyển đổi Ethernet Intel RJ45
Công tắc FC 16Gb/s
Thổ cẩm 6505
Cổng 10GbE riêng chuyên dụng để đồng bộ hóa dữ liệu
Intel X520
AccelStor NeoSapphire™ Tất cả thông số kỹ thuật của mảng Flash
Thành phần
Описание
Hệ thống lưu trữ
Mẫu NeoSapphire™ có tính sẵn sàng cao: H710
Phiên bản hình ảnh
4.0.1
Tổng số ổ đĩa
48
Kích thước ổ đĩa
1.92TB
Loại ổ
SSD
Cổng mục tiêu FC
Cổng 16x 16Gb (8 cổng mỗi nút)
Các cổng quản lý
Cáp ethernet 1GbE kết nối với máy chủ thông qua bộ chuyển mạch ethernet
Cổng nhịp tim
Cáp ethernet 1GbE kết nối giữa hai nút lưu trữ
Cổng đồng bộ dữ liệu
Cáp InfiniBand 56Gb/s
Trước khi bạn có thể sử dụng một mảng, bạn phải khởi tạo nó. Theo mặc định, địa chỉ điều khiển của cả hai nút là như nhau (192.168.1.1). Bạn cần kết nối từng cái một với chúng và đặt địa chỉ quản lý mới (đã khác) cũng như thiết lập đồng bộ hóa thời gian, sau đó các cổng Quản lý có thể được kết nối với một mạng duy nhất. Sau đó, các nút được kết hợp thành một cặp HA bằng cách gán mạng con cho các kết nối Liên kết.
Sau khi khởi tạo hoàn tất, bạn có thể quản lý mảng từ bất kỳ nút nào.
Tiếp theo, chúng tôi tạo các tập cần thiết và xuất bản chúng lên máy chủ ứng dụng.
Chúng tôi khuyên bạn nên tạo nhiều ổ đĩa cho Oracle ASM vì điều này sẽ tăng số lượng mục tiêu cho máy chủ, điều này cuối cùng sẽ cải thiện hiệu suất tổng thể (nhiều hơn về hàng đợi trong một trang khác). ).
Kiểm tra cấu hình
Tên dung lượng lưu trữ
Khối lượng
Dữ liệu01
200GB
Dữ liệu02
200GB
Dữ liệu03
200GB
Dữ liệu04
200GB
Dữ liệu05
200GB
Dữ liệu06
200GB
Dữ liệu07
200GB
Dữ liệu08
200GB
Dữ liệu09
200GB
Dữ liệu10
200GB
Lưới01
1GB
Lưới02
1GB
Lưới03
1GB
Lưới04
1GB
Lưới05
1GB
Lưới06
1GB
Làm lại01
100GB
Làm lại02
100GB
Làm lại03
100GB
Làm lại04
100GB
Làm lại05
100GB
Làm lại06
100GB
Làm lại07
100GB
Làm lại08
100GB
Làm lại09
100GB
Làm lại10
100GB
Một số giải thích về các chế độ hoạt động của mảng và các quá trình xảy ra trong tình huống khẩn cấp
Tập dữ liệu của mỗi nút có tham số “số phiên bản”. Sau lần khởi tạo ban đầu, nó giống nhau và bằng 1. Nếu vì lý do nào đó mà số phiên bản khác nhau thì dữ liệu luôn được đồng bộ hóa từ phiên bản cũ hơn sang phiên bản trẻ hơn, sau đó số của phiên bản trẻ hơn sẽ được căn chỉnh, tức là. điều này có nghĩa là các bản sao giống hệt nhau. Lý do tại sao các phiên bản có thể khác nhau:
- Khởi động lại theo lịch trình của một trong các nút
- Sự cố xảy ra ở một trong các nút do tắt đột ngột (nguồn điện, quá nhiệt, v.v.).
- Mất kết nối InfiniBand do không thể đồng bộ hóa
- Sự cố trên một trong các nút do hỏng dữ liệu. Tại đây, bạn sẽ cần tạo một nhóm HA mới và đồng bộ hóa hoàn toàn tập dữ liệu.
Trong mọi trường hợp, nút vẫn trực tuyến sẽ tăng số phiên bản của nó lên một để đồng bộ hóa tập dữ liệu của nó sau khi kết nối với cặp được khôi phục.
Nếu kết nối qua liên kết Ethernet bị mất, Heartbeat sẽ tạm thời chuyển sang InfiniBand và quay trở lại trong vòng 10 giây khi được khôi phục.
Thiết lập máy chủ
Để đảm bảo khả năng chịu lỗi và cải thiện hiệu suất, bạn phải kích hoạt hỗ trợ MPIO cho mảng. Để thực hiện việc này, bạn cần thêm dòng vào tệp /etc/multipath.conf, sau đó khởi động lại dịch vụ đa đường dẫn
Văn bản bị ẩnthiết bị {
thiết bị {
nhà cung cấp "AStor"
path_grouping_policy "group_by_prio"
path_selector "độ dài hàng đợi 0"
path_checker "tur"
tính năng "0"
phần cứng_handler "0"
trước "const"
thất bại ngay lập tức
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names có
detect_prio vâng
rr_min_io_rq 1
no_path_retry 0
}
}
Tiếp theo, để ASM hoạt động với MPIO thông qua ASMLib, bạn cần thay đổi tệp /etc/sysconfig/oracleasm rồi chạy /etc/init.d/oracleasm scandisks
Văn bản bị ẩn
# ORACLEASM_SCANORDER: So khớp các mẫu để ra lệnh quét đĩa
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: So khớp các mẫu để loại trừ đĩa khỏi quá trình quét
ORACLEASM_SCANEXCLUDE="sd"
Ghi
Nếu bạn không muốn sử dụng ASMLib, bạn có thể sử dụng các quy tắc UDEV, là cơ sở cho ASMLib.
Bắt đầu với phiên bản 12.1.0.2 của Cơ sở dữ liệu Oracle, tùy chọn này có sẵn để cài đặt như một phần của phần mềm ASMFD.
Điều bắt buộc là phải đảm bảo rằng các đĩa được tạo cho Oracle ASM được căn chỉnh theo kích thước khối mà mảng hoạt động vật lý với (4K). Nếu không, vấn đề về hiệu suất có thể xảy ra. Vì vậy cần tạo các khối có thông số phù hợp:
parted /dev/mapper/device-name mklabel gpt mkpart Primary 2048s 100% căn chỉnh-kiểm tra tối ưu 1
Phân phối cơ sở dữ liệu trên các khối đã tạo cho cấu hình thử nghiệm của chúng tôi
Tên dung lượng lưu trữ
Khối lượng
Ánh xạ LUN khối lượng
Chi tiết thiết bị khối lượng ASM
Kích thước đơn vị phân bổ
Dữ liệu01
200GB
Ánh xạ tất cả các khối lưu trữ vào hệ thống lưu trữ tất cả các cổng dữ liệu
Dự phòng: Bình thường
Tên: DGDATA
Mục đích: File dữ liệu
4MB
Dữ liệu02
200GB
Dữ liệu03
200GB
Dữ liệu04
200GB
Dữ liệu05
200GB
Dữ liệu06
200GB
Dữ liệu07
200GB
Dữ liệu08
200GB
Dữ liệu09
200GB
Dữ liệu10
200GB
Lưới01
1GB
Dự phòng: Bình thường
Tên: DGGRID1
Mục đích:Lưới: CRS và Biểu quyết
4MB
Lưới02
1GB
Lưới03
1GB
Lưới04
1GB
Dự phòng: Bình thường
Tên: DGGRID2
Mục đích:Lưới: CRS và Biểu quyết
4MB
Lưới05
1GB
Lưới06
1GB
Làm lại01
100GB
Dự phòng: Bình thường
Tên: DGREDO1
Mục đích: Làm lại log của thread 1
4MB
Làm lại02
100GB
Làm lại03
100GB
Làm lại04
100GB
Làm lại05
100GB
Làm lại06
100GB
Dự phòng: Bình thường
Tên: DGREDO2
Mục đích: Làm lại log của thread 2
4MB
Làm lại07
100GB
Làm lại08
100GB
Làm lại09
100GB
Làm lại10
100GB
Cài đặt cơ sở dữ liệu
- Kích thước khối = 8K
- Dung lượng trao đổi = 16GB
- Vô hiệu hóa AMM (Quản lý bộ nhớ tự động)
- Vô hiệu hóa các trang lớn trong suốt
Các thiết lập khác
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # không đặt cái này nếu bạn đang sử dụng Linux x86
✓ vm.vfs_cache_ Pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ lưới mềm nproc 2047
✓ lưới cứng nproc 16384
✓ lưới mềm nofile 1024
✓ lưới cứng nofile 65536
✓ lưới ngăn xếp mềm 10240
✓ ngăn xếp lưới cứng 32768
✓ Oracle mềm nproc 2047
✓ Oracle cứng nproc 16384
✓ tập tin mềm oracle 1024
✓ tập tin cứng oracle 65536
✓ ngăn xếp mềm oracle 10240
✓ ngăn xếp cứng oracle 32768
✓ memlock mềm 120795954
✓ memlock cứng 120795954
sqlplus “/as sysdba”
thay đổi hệ thống thiết lập quy trình=2000 phạm vi=spfile;
thay đổi hệ thống được đặt open_cursors=2000 phạm vi=spfile;
thay đổi bộ hệ thống session_cached_cursors=300 phạm vi=spfile;
thay đổi bộ hệ thống db_files=8192 phạm vi=spfile;
Kiểm tra thất bại
Với mục đích trình diễn, HammerDB đã được sử dụng để mô phỏng tải OLTP. Cấu hình HammerDB:
Số lượng kho
256
Tổng số giao dịch trên mỗi người dùng
1000000000000
Người dùng ảo
256
Kết quả là TPM 2.1M, vượt xa giới hạn hiệu suất của mảng , nhưng là “mức trần” cho cấu hình phần cứng hiện tại của máy chủ (chủ yếu do bộ xử lý) và số lượng của chúng. Mục đích của thử nghiệm này vẫn là để chứng minh khả năng chịu lỗi của toàn bộ giải pháp chứ không phải để đạt được hiệu suất tối đa. Vì vậy, chúng tôi sẽ chỉ xây dựng trên con số này.
Kiểm tra lỗi của một trong các nút
Các máy chủ đã mất một phần đường dẫn đến bộ lưu trữ, tiếp tục xử lý các đường dẫn còn lại bằng nút thứ hai. Hiệu suất giảm trong vài giây do đường dẫn được xây dựng lại và sau đó trở lại bình thường. Không có sự gián đoạn trong dịch vụ.
Kiểm tra lỗi tủ với tất cả các thiết bị
Trong trường hợp này, hiệu suất cũng giảm trong vài giây do tái cấu trúc các đường dẫn, sau đó quay trở lại một nửa giá trị ban đầu. Kết quả đã giảm một nửa so với kết quả ban đầu do loại trừ một máy chủ ứng dụng khỏi hoạt động. Dịch vụ cũng không bị gián đoạn.
Nếu có nhu cầu triển khai giải pháp khắc phục thảm họa Cross-Rack có khả năng chịu lỗi cho Oracle với chi phí hợp lý và ít nỗ lực triển khai/quản trị, thì Oracle RAC và kiến trúc sẽ phối hợp với nhau sẽ là một trong những lựa chọn tốt nhất. Thay vì Oracle RAC, có thể có bất kỳ phần mềm nào khác cung cấp khả năng phân cụm, chẳng hạn như DBMS hoặc hệ thống ảo hóa tương tự. Nguyên tắc xây dựng giải pháp sẽ được giữ nguyên. Và điểm mấu chốt là bằng XNUMX đối với RTO và RPO.
Nguồn: www.habr.com