Phục hồi thảm họa cho Databricks đề cập đến một tập hợp các chính sách, công cụ và quy trình. Nó cho phép khôi phục hoặc tiếp tục cơ sở hạ tầng và hệ thống công nghệ quan trọng sau hậu quả của thảm họa tự nhiên hoặc do con người gây ra.
Mặc dù các Nhà cung cấp dịch vụ đám mây như AWS, Azure, Google Cloud và các công ty SaaS xây dựng các biện pháp bảo vệ chống lại các điểm lỗi đơn lẻ, lỗi vẫn xảy ra. Mức độ nghiêm trọng của sự gián đoạn và tác động của nó đối với một tổ chức có thể khác nhau. Đối với khối lượng công việc gốc trên đám mây, một mẫu khôi phục thảm họa rõ ràng là rất quan trọng.
Mục lục
Thiết lập khôi phục thảm họa cho Databricks
Vui lòng xem các bài đăng blog trước trong loạt blog DR này. Mục đích để hiểu các bước từ một đến bốn về cách lập kế hoạch. Thiết lập chiến lược giải pháp DR và tự động hóa. Trong bước năm và sáu của bài đăng trên blog này. Chúng tôi sẽ xem xét cách giám sát, thực thi và xác thực thiết lập DR.
Giải pháp khắc phục thảm họa Databricks
Việc triển khai Databricks điển hình bao gồm một số nội dung quan trọng. Chẳng hạn như mã nguồn sổ ghi chép, truy vấn, cấu hình công việc và cụm, phải được khôi phục suôn sẻ để đảm bảo giảm thiểu gián đoạn và tiếp tục cung cấp dịch vụ cho người dùng cuối.
Xem xét DR cấp cao:
Đảm bảo kiến trúc của bạn có thể sao chép được thông qua Terraform (TF) , giúp bạn có thể tạo và tạo lại môi trường này ở nơi khác.
Sử dụng Databricks Repos ( AWS | Azure | GCP ) để đồng bộ Notebook và mã ứng dụng trong các tệp tùy ý được hỗ trợ ( AWS | Azure | GCP ).
Sử dụng Terraform Cloud để kích hoạt chạy TF (lập kế hoạch và áp dụng) cho hạ tầng cơ sở và đường ống ứng dụng trong khi duy trì trạng thái
Các bước tiếp theo
Sao chép dữ liệu từ các tài khoản lưu trữ đám mây như Amazon S3, Azure ADLS và GCS sang vùng DR. Nếu đang sử dụng AWS, bạn cũng có thể lưu trữ dữ liệu bằng cách sử dụng Điểm truy cập đa vùng S3 để dữ liệu trải dài trên nhiều vùng chứa S3 ở các Khu vực AWS khác nhau.
Các định nghĩa cụm Databricks có thể chứa thông tin cụ thể về vùng khả dụng. Sử dụng thuộc tính cụm “auto-az” khi chạy Databricks trên AWS để tránh mọi sự cố trong quá trình chuyển đổi dự phòng khu vực.
Quản lý trôi cấu hình tại Vùng DR. Đảm bảo rằng cơ sở hạ tầng, dữ liệu và cấu hình của bạn là cần thiết trong Vùng DR.
Ví dụ
Đối với nội dung và mã sản xuất, hãy sử dụng công cụ CI/CD để đẩy các thay đổi Databricks đối với hệ thống sản xuất đồng thời tới cả hai khu vực. Ví dụ: khi đẩy mã và nội dung từ dàn dựng/phát triển sang sản xuất, hệ thống CI/CD sẽ cung cấp nội dung đó ở cả hai khu vực cùng một lúc.
Sử dụng Git để đồng bộ hóa các tệp TF và cơ sở mã cơ sở hạ tầng, cấu hình công việc và cấu hình cụm.
Các cấu hình dành riêng cho khu vực sẽ cần được cập nhật trước khi chạy TF `áp dụng` trong khu vực phụ.
Lưu ý:
Một số dịch vụ như Kho tính năng, quy trình MLflow, theo dõi thử nghiệm ML. Quản lý Mô hình và triển khai Mô hình. Nó không thể được coi là khả thi tại thời điểm này đối với Khắc phục sự cố. Đối với Truyền trực tuyến có cấu trúc và Bảng trực tiếp Delta. Việc triển khai tích cự hoạt động là cần thiết để duy trì đảm bảo chính xác một lần. Nhưng quy trình cuối cùng sẽ có sự nhất quán giữa hai khu vực.
Bạn có thể tìm thấy các cân nhắc bổ sung ở cấp độ cao trong các bài viết trước.
Giám sát và Phát hiện
Điều quan trọng là phải biết càng sớm càng tốt nếu công việc của bạn không ở trạng thái tốt. Mục đích để bạn có thể nhanh chóng tuyên bố thảm họa và khôi phục Databricks sau sự cố. Thời gian phản hồi này cùng với thông tin thích hợp là rất quan trọng trong việc đáp ứng các mục tiêu khôi phục tích cực. Điều quan trọng là phải phát hiện, thông báo, leo thang, khám phá và tuyên bố sự cố trong kế hoạch và mục tiêu của bạn để cung cấp các mục tiêu thực tế, có thể đạt được.
Thông báo trạng thái dịch vụ Databricks
Trang Trạng thái Databricks cung cấp tổng quan về tất cả các dịch vụ Databricks cốt lõi cho mặt phẳng điều khiển. Bạn có thể dễ dàng xem trạng thái của một dịch vụ cụ thể bằng cách xem trang trạng thái. Theo tùy chọn, bạn có thể đăng ký cập nhật trạng thái trên các thành phần dịch vụ riêng lẻ. Nó sẽ gửi cảnh báo bất cứ khi nào trạng thái bạn đăng ký thay đổi.
Để kiểm tra trạng thái liên quan đến mặt phẳng dữ liệu, AWS Health Dashboard , Azure Status Page và GCP Service Health Page nên được sử dụng để theo dõi.
AWS và Azure cung cấp các điểm cuối API. Mà các công cụ có thể sử dụng để nhập và cảnh báo khi kiểm tra trạng thái.
Giám sát và cảnh báo cơ sở hạ tầng
Việc sử dụng một công cụ Databricks để thu thập và phân tích dữ liệu từ cơ sở hạ tầng. Nó cho phép các nhóm theo dõi hiệu suất theo thời gian. Điều này chủ động trao quyền cho các nhóm để giảm thiểu thời gian chết. Đồng thời việc suy thoái dịch vụ nói chung. Ngoài ra, việc theo dõi theo thời gian sẽ thiết lập một đường cơ sở cho hiệu suất cao nhất. Nó cần thiết để làm tham chiếu cho việc tối ưu hóa và cảnh báo.
Lưu ý
Trong ngữ cảnh DR, một tổ chức có thể không chờ cảnh báo từ các nhà cung cấp dịch vụ. Ngay cả khi các yêu cầu RTO/RPO đủ cho phép để chờ cảnh báo từ nhà cung cấp dịch vụ. Thì việc thông báo trước cho nhóm hỗ trợ của nhà cung cấp về tình trạng suy giảm hiệu suất. Nó sẽ mở ra một đường dây liên lạc sớm hơn.
Cả DataDog và Dynatrace đều là những công cụ giám sát phổ biến cung cấp các tích hợp và tác nhân cho các cụm AWS, Azure, GCP và Databricks.
Kiểm tra sức khỏe Databricks
Đối với các yêu cầu RTO nghiêm ngặt nhất, bạn có thể triển khai chuyển đổi dự phòng tự động dựa trên kiểm tra tình trạng của Dịch vụ Databricks. Và các dịch vụ khác mà khối lượng công việc giao tiếp trực tiếp trong Mặt phẳng dữ liệu. Chẳng hạn như kho lưu trữ đối tượng và dịch vụ VM từ nhà cung cấp đám mây.
Thiết kế kiểm tra sức khỏe
Thiết kế kiểm tra sức khỏe đại diện cho trải nghiệm người dùng và dựa trên Chỉ số hiệu suất chính. Kiểm tra nhịp tim nông có thể đánh giá xem hệ thống có đang hoạt động hay không. Tức là nếu cụm Databricks đang chạy. Trong khi kiểm tra tình trạng chuyên sâu.
Chẳng hạn như chỉ số hệ thống từ CPU của các nút riêng lẻ. Ngoài ra, còn có mức sử dụng đĩa và chỉ số Spark trên từng giai đoạn hoạt động hoặc phân vùng được lưu trong bộ nhớ cache. Hãy vượt qua các kiểm tra nhịp tim nông để xác định sự xuống cấp đáng kể về hiệu suất. Sử dụng kiểm tra tình trạng sâu dựa trên nhiều tín hiệu theo chức năng và hiệu suất cơ bản của khối lượng công việc.
Chú ý
Thận trọng nếu tự động hóa hoàn toàn quyết định chuyển đổi dự phòng bằng kiểm tra tình trạng. Nếu xảy ra thông báo sai hoặc cảnh báo được kích hoạt. Nhưng doanh nghiệp có thể chịu được tác động thì không cần phải chuyển đổi dự phòng.
Chuyển đổi dự phòng sai dẫn đến các rủi ro về tính khả dụng và rủi ro hỏng dữ liệu. Đồng thời là một hoạt động tốn kém về mặt thời gian. Bạn nên có một người trực tiếp. Ví dụ người quản lý sự cố theo yêu cầu. Mục đích để đưa ra quyết định nếu báo động được kích hoạt. Chuyển đổi dự phòng không cần thiết có thể là thảm họa. Và việc xem xét bổ sung giúp xác định xem có cần chuyển đổi dự phòng hay không.
Thực thi giải pháp DR
Hai kịch bản thực thi tồn tại ở mức cao đối với giải pháp Khắc phục sự cố. Trong trường hợp đầu tiên, trang web DR được coi là tạm thời. Sau khi dịch vụ được khôi phục tại trang chính. Giải pháp phải sắp xếp chuyển đổi dự phòng từ trang DR sang trang chính, cố định. Không nên hạn chế tạo các tạo phẩm mới trong khi trang DR đang hoạt động.
Vì nó chỉ là tạm thời và làm phức tạp quá trình dự phòng trong trường hợp này. Ngược lại, trong kịch bản thứ hai, trang DR sẽ được nâng cấp lên trang chính mới. Nó cho phép người dùng Databricks tiếp tục công việc nhanh hơn. Vì họ không cần đợi dịch vụ được khôi phục. Hơn nữa, trường hợp này không yêu cầu dự phòng. Nhưng trang web chính cũ phải được chuẩn bị làm trang web DR mới.
Trong cả hai trường hợp, mỗi khu vực trong phạm vi của giải pháp DR phải hỗ trợ tất cả các dịch vụ được yêu cầu. Nó phải tồn tại một quy trình xác thực không gian làm việc đích ở tình trạng hoạt động tốt. Nó như một biện pháp bảo vệ. Quá trình xác thực có thể bao gồm xác thực mô phỏng, truy vấn tự động. Lệnh gọi API và kiểm tra ACL.
Chuyển đổi dự phòng Databricks
Khi kích hoạt chuyển đổi dự phòng sang trang DR. Giải pháp không thể cho rằng khả năng tắt hệ thống một cách nhẹ nhàng là có thể. Giải pháp sẽ cố gắng tắt các dịch vụ đang chạy trong trang web chính. Ghi lại trạng thái tắt cho từng dịch vụ. Sau đó tiếp tục cố gắng tắt các dịch vụ không có trạng thái thích hợp trong một khoảng thời gian xác định. Điều này làm giảm rủi ro khi dữ liệu được xử lý đồng thời ở cả trang chính và trang DR. Giảm thiểu hỏng hóc dữ liệu. Đồng thời nó còn tạo thuận lợi cho quy trình dự phòng sau khi dịch vụ được khôi phục.
Các bước cấp cao để kích hoạt trang DR bao gồm:
Chuẩn bị
Chạy một quy trình tắt máy trên trang web chính để tắt các nhóm, cụm và công việc đã lên lịch trên khu vực chính. Nếu dịch vụ bị lỗi trở lại trực tuyến, thì khu vực chính sẽ không bắt đầu xử lý dữ liệu mới.
Xác nhận rằng cấu hình và cơ sở hạ tầng trang web DR được cập nhật.
Kiểm tra ngày của dữ liệu được đồng bộ hóa mới nhất. Xem Thuật ngữ ngành khắc phục thảm họa . Chi tiết của bước này khác nhau dựa trên cách bạn đồng bộ hóa dữ liệu và nhu cầu kinh doanh duy nhất.
Ổn định nguồn dữ liệu của bạn và đảm bảo rằng tất cả chúng đều có sẵn. Bao gồm tất cả các nguồn dữ liệu ngoài quan trọng. Chẳng hạn như lưu trữ đối tượng, cơ sở dữ liệu, hệ thống quán rượu/phụ, v.v.
Thông báo cho người dùng nền tảng.
Tiến hành
Bắt đầu các nhóm có liên quan (hoặc tăng min_idle_instances thành các số có liên quan).
Bắt đầu các cụm, công việc và Kho SQL có liên quan (nếu chưa chấm dứt).
Thay đổi chạy đồng thời cho các công việc và chạy các công việc có liên quan. Đây có thể là chạy một lần hoặc chạy định kỳ.
Kích hoạt lịch trình công việc.
Đối với bất kỳ công cụ bên ngoài nào sử dụng URL hoặc tên miền cho không gian làm việc Databricks của bạn. Hãy cập nhật cấu hình để tính đến mặt phẳng điều khiển mới. Ví dụ: cập nhật URL cho API REST và kết nối JDBC/ODBC. URL hướng tới khách hàng của ứng dụng web Databricks thay đổi khi mặt phẳng điều khiển thay đổi. Vì vậy hãy thông báo cho người dùng trong tổ chức của bạn về URL mới.
Dự phòng
Việc quay lại trang Chính trong quá trình Dự phòng sẽ dễ kiểm soát hơn và có thể được thực hiện trong thời gian bảo trì. Dự phòng sẽ tuân theo một kế hoạch rất giống với Dự phòng, với bốn ngoại lệ chính:
- Vùng mục tiêu sẽ là vùng chính.
- Vì Dự phòng là một quy trình được kiểm soát, tắt máy là hoạt động một lần không yêu cầu kiểm tra trạng thái để tắt các dịch vụ khi chúng trực tuyến trở lại.
- Trang web DR sẽ cần được đặt lại nếu cần cho bất kỳ chuyển đổi dự phòng nào trong tương lai.
- Mọi bài học kinh nghiệm nên được tích hợp vào giải pháp DR và thử nghiệm cho các sự kiện thảm họa trong tương lai.
Phần kết luận
Thường xuyên kiểm tra thiết lập khôi phục thảm họa của bạn trong điều kiện thực tế để đảm bảo thiết lập hoạt động bình thường. Không có ích gì khi giữ một giải pháp khắc phục thảm họa không thể sử dụng khi cần thiết. Một số tổ chức kiểm tra cơ sở hạ tầng DR bằng cách thực hiện chuyển đổi dự phòng. Và dự phòng giữa các vùng vài tháng một lần.
Trên cơ sở thường xuyên, chuyển đổi dự phòng sang trang DR sẽ kiểm tra các giả định và quy trình của bạn. Mục đích để đảm bảo rằng chúng đáp ứng các yêu cầu khôi phục về RPO và RTO. Điều này cũng đảm bảo rằng các chính sách và thủ tục khẩn cấp của tổ chức được cập nhật. Kiểm tra bất kỳ thay đổi tổ chức nào được yêu cầu đối với các quy trình và cấu hình của bạn nói chung. Kế hoạch khắc phục thảm họa của bạn có tác động đến quy trình triển khai của bạn. Vì vậy hãy đảm bảo nhóm của bạn biết những gì cần được đồng bộ hóa.
Nguồn: Internet