Càng ngày, khách hàng càng nhận được những yêu cầu sau: “Chúng tôi muốn nó giống như Amazon RDS, nhưng rẻ hơn”; “Chúng tôi muốn nó giống như RDS, nhưng ở mọi nơi, trong mọi cơ sở hạ tầng.” Để triển khai giải pháp được quản lý như vậy trên Kubernetes, chúng tôi đã xem xét trạng thái hiện tại của các toán tử phổ biến nhất cho PostgreSQL (Stolon, toán tử từ Crunchy Data và Zalando) và đưa ra lựa chọn của mình.
Bài viết này là kinh nghiệm chúng tôi thu được cả từ góc độ lý thuyết (xem xét các giải pháp) và từ khía cạnh thực tiễn (điều gì đã được chọn và điều gì đã xảy ra). Nhưng trước tiên, hãy xác định những yêu cầu chung để có thể thay thế RDS...
RDS là gì
Theo kinh nghiệm của chúng tôi, khi mọi người nói về RDS, họ muốn nói đến một dịch vụ DBMS được quản lý:
- dễ dàng cấu hình;
- có khả năng làm việc với ảnh chụp nhanh và khôi phục từ chúng (tốt nhất là có hỗ trợ );
- cho phép bạn tạo cấu trúc liên kết chủ-nô lệ;
- có danh sách tiện ích mở rộng phong phú;
- cung cấp khả năng kiểm tra và quản lý người dùng/truy cập.
Nói chung, các cách tiếp cận để thực hiện nhiệm vụ hiện tại có thể rất khác nhau, nhưng con đường với Ansible có điều kiện không gần với chúng ta. (Kết quả là các đồng nghiệp từ 2GIS đã đi đến kết luận tương tự tạo "một công cụ để triển khai nhanh chóng cụm chuyển đổi dự phòng dựa trên Postgres.")
Toán tử là cách tiếp cận phổ biến để giải quyết các vấn đề tương tự trong hệ sinh thái Kubernetes. Giám đốc kỹ thuật của “Flanta” đã nói chi tiết hơn về chúng liên quan đến cơ sở dữ liệu được triển khai bên trong Kubernetes. Trong .
NB: Để nhanh chóng tạo các toán tử đơn giản, chúng tôi khuyên bạn nên chú ý đến tiện ích Nguồn mở của chúng tôi . Khi sử dụng nó, bạn có thể thực hiện việc này mà không cần kiến thức về Go, nhưng theo những cách quen thuộc hơn với quản trị viên hệ thống: trong Bash, Python, v.v.
Có một số toán tử K8 phổ biến cho PostgreSQL:
- Stolon;
- Toán tử PostgreSQL dữ liệu giòn;
- Nhà điều hành Zalando Postgres.
Chúng ta hãy nhìn vào chúng kỹ hơn.
Lựa chọn toán tử
Ngoài các tính năng quan trọng đã được đề cập ở trên, chúng tôi - với tư cách là kỹ sư vận hành cơ sở hạ tầng Kubernetes - cũng mong đợi những điều sau từ các nhà khai thác:
- triển khai từ Git và với ;
- hỗ trợ chống ái lực nhóm;
- cài đặt mối quan hệ nút hoặc bộ chọn nút;
- lắp đặt dung sai;
- sự sẵn có của khả năng điều chỉnh;
- công nghệ dễ hiểu và thậm chí cả các lệnh.
Không đi sâu vào chi tiết từng điểm (hãy hỏi trong phần nhận xét nếu bạn vẫn còn thắc mắc về chúng sau khi đọc toàn bộ bài viết), nói chung tôi sẽ lưu ý rằng những tham số này là cần thiết để mô tả chính xác hơn tính chuyên môn hóa của các nút cụm nhằm đặt hàng chúng cho các ứng dụng cụ thể. Bằng cách này, chúng ta có thể đạt được sự cân bằng tối ưu về hiệu suất và chi phí.
Bây giờ chúng ta hãy chuyển sang các toán tử PostgreSQL.
1. Tấm bia
từ công ty Sorint.lab của Ý ở được coi là một loại tiêu chuẩn trong số các nhà khai thác DBMS. Đây là một dự án khá cũ: lần phát hành công khai đầu tiên của nó diễn ra vào tháng 2015 năm 3000(!), và kho GitHub tự hào có gần 40 sao và hơn XNUMX người đóng góp.
Quả thực, Stolon là một ví dụ tuyệt vời về kiến trúc chu đáo:
Thiết bị của nhà điều hành này có thể được tìm thấy chi tiết trong báo cáo hoặc . Nói chung, chỉ cần nói rằng nó có thể thực hiện mọi thứ được mô tả: chuyển đổi dự phòng, proxy để truy cập máy khách minh bạch, sao lưu... Hơn nữa, proxy cung cấp quyền truy cập thông qua một dịch vụ điểm cuối - không giống như hai giải pháp còn lại được thảo luận bên dưới (mỗi giải pháp đều có hai dịch vụ cho truy cập cơ sở).
Tuy nhiên, Stolon , đó là lý do tại sao nó không thể được triển khai theo cách dễ dàng và nhanh chóng – “như tôm tươi” – để tạo các phiên bản DBMS trong Kubernetes. Việc quản lý được thực hiện thông qua tiện ích stolonctl, việc triển khai được thực hiện thông qua biểu đồ Helm và các biểu đồ tùy chỉnh được xác định và chỉ định trong ConfigMap.
Một mặt, hóa ra toán tử không thực sự là toán tử (xét cho cùng, nó không sử dụng CRD). Nhưng mặt khác, đây là một hệ thống linh hoạt cho phép bạn định cấu hình tài nguyên trong K8 khi bạn thấy phù hợp.
Tóm lại, đối với cá nhân chúng tôi, việc tạo một biểu đồ riêng cho từng cơ sở dữ liệu có vẻ không phải là tối ưu. Vì vậy, chúng tôi bắt đầu tìm kiếm các lựa chọn thay thế.
2. Toán tử PostgreSQL dữ liệu giòn
, một công ty khởi nghiệp trẻ của Mỹ, dường như là một sự thay thế hợp lý. Lịch sử công khai của nó bắt đầu với lần phát hành đầu tiên vào tháng 2017 năm 1300, kể từ đó kho lưu trữ GitHub chỉ nhận được dưới 50 sao và hơn 1.15 người đóng góp. Bản phát hành mới nhất từ tháng 1.18 đã được thử nghiệm để hoạt động với Kubernetes 3.11-4.4, OpenShift 1.3+ và XNUMX+, GKE và VMware Enterprise PKS XNUMX+.
Kiến trúc của Crunchy Data PostgreSQL Operator cũng đáp ứng các yêu cầu đã nêu:
Quản lý xảy ra thông qua tiện ích pgotuy nhiên, nó lại tạo ra Tài nguyên tùy chỉnh cho Kubernetes. Do đó, nhà điều hành làm hài lòng chúng tôi với tư cách là người dùng tiềm năng:
- có sự điều khiển thông qua CRD;
- quản lý người dùng thuận tiện (cũng thông qua CRD);
- tích hợp với các thành phần khác - một bộ sưu tập chuyên biệt các hình ảnh vùng chứa cho PostgreSQL và các tiện ích để làm việc với nó (bao gồm pgBackRest, pgAudit, các tiện ích mở rộng từ contrib, v.v.).
Tuy nhiên, những nỗ lực bắt đầu sử dụng toán tử từ Crunchy Data đã bộc lộ một số vấn đề:
- Không có khả năng dung nạp - chỉ nodeSelector được cung cấp.
- Các nhóm được tạo là một phần của Triển khai, mặc dù thực tế là chúng tôi đã triển khai một ứng dụng có trạng thái. Không giống như StatefulSets, Triển khai không thể tạo đĩa.
Hạn chế cuối cùng dẫn đến những khoảnh khắc buồn cười: trên môi trường thử nghiệm, chúng tôi đã chạy được 3 bản sao trên một đĩa lưu trữ cục bộ, khiến người vận hành báo cáo rằng 3 bản sao đang hoạt động (mặc dù chúng không hoạt động).
Một tính năng khác của nhà điều hành này là tích hợp sẵn với các hệ thống hỗ trợ khác nhau. Ví dụ: thật dễ dàng để cài đặt pgAdmin và pgBounce, và trong Grafana và Prometheus được cấu hình sẵn sẽ được xem xét. Trong gần đây Cải thiện khả năng tích hợp với dự án được ghi chú riêng , nhờ đó, nhà điều hành cung cấp một hình ảnh trực quan rõ ràng về các số liệu PGSQL ngay lập tức.
Tuy nhiên, sự lựa chọn kỳ lạ về các tài nguyên do Kubernetes tạo ra đã khiến chúng tôi phải tìm ra một giải pháp khác.
3. Nhà điều hành Zalando Postgres
Chúng tôi đã biết đến các sản phẩm của Zalando từ lâu: chúng tôi có kinh nghiệm sử dụng Zalenium và tất nhiên, chúng tôi đã thử là giải pháp HA phổ biến của họ dành cho PostgreSQL. Về phương pháp tạo ra của công ty một trong những tác giả của nó, Alexey Klyukin, đã nói trên sóng , và chúng tôi thích nó.
Đây là giải pháp trẻ nhất được thảo luận trong bài viết: lần phát hành đầu tiên diễn ra vào tháng 2018 năm 1300. Tuy nhiên, ngay cả khi số lượng bản phát hành chính thức còn ít, dự án đã đi được một chặng đường dài, vượt qua giải pháp về mức độ phổ biến từ Crunchy Data với hơn 70 sao trên GitHub và số lượng người đóng góp tối đa (XNUMX+).
“Dưới mui xe” nhà điều hành này sử dụng các giải pháp đã được thử nghiệm theo thời gian:
- Patroni và Cho việc lái xe,
- - để sao lưu,
- - như một nhóm kết nối.
Đây là cách trình bày kiến trúc toán tử từ Zalando:
Người vận hành được quản lý hoàn toàn thông qua Tài nguyên tùy chỉnh, tự động tạo StatefulSet từ các vùng chứa, sau đó có thể tùy chỉnh bằng cách thêm nhiều sidecar khác nhau vào nhóm. Tất cả điều này là một lợi thế đáng kể so với toán tử từ Crunchy Data.
Vì chúng tôi đã chọn giải pháp Zalando trong số 3 lựa chọn đang được xem xét nên phần mô tả thêm về khả năng của nó sẽ được trình bày bên dưới, ngay cùng với việc thực hành ứng dụng.
Thực hành với Toán tử Postgres từ Zalando
Việc triển khai toán tử rất đơn giản: chỉ cần tải xuống bản phát hành hiện tại từ GitHub và áp dụng các tệp YAML từ thư mục . Ngoài ra, bạn cũng có thể sử dụng .
Sau khi cài đặt, bạn nên lo lắng về việc thiết lập . Việc này được thực hiện thông qua ConfigMap postgres-operator trong không gian tên nơi bạn đã cài đặt toán tử. Sau khi định cấu hình các kho lưu trữ, bạn có thể triển khai cụm PostgreSQL đầu tiên của mình.
Ví dụ: quá trình triển khai tiêu chuẩn của chúng tôi trông như thế này:
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: staging-db
spec:
numberOfInstances: 3
patroni:
synchronous_mode: true
postgresql:
version: "12"
resources:
limits:
cpu: 100m
memory: 1Gi
requests:
cpu: 100m
memory: 1Gi
sidecars:
- env:
- name: DATA_SOURCE_URI
value: 127.0.0.1:5432
- name: DATA_SOURCE_PASS
valueFrom:
secretKeyRef:
key: password
name: postgres.staging-db.credentials
- name: DATA_SOURCE_USER
value: postgres
image: wrouesnel/postgres_exporter
name: prometheus-exporter
resources:
limits:
cpu: 500m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
teamId: staging
volume:
size: 2Gi
Tệp kê khai này triển khai một cụm gồm 3 phiên bản có sidecar ở dạng , từ đó chúng tôi lấy số liệu ứng dụng. Như bạn có thể thấy, mọi thứ đều rất đơn giản và nếu muốn, bạn có thể tạo số lượng cụm không giới hạn theo đúng nghĩa đen.
Đó là giá trị chú ý đến bảng quản trị web - . Nó đi kèm với toán tử và cho phép bạn tạo và xóa các cụm cũng như làm việc với các bản sao lưu do toán tử tạo.
Danh sách các cụm PostgreSQL
Quản lý sao lưu
Một tính năng thú vị khác là hỗ trợ . Cơ chế này tự động tạo ra vai trò trong PostgreSQL, dựa trên danh sách tên người dùng kết quả. Sau đó, API cho phép bạn trả về danh sách người dùng có vai trò được tạo tự động.
Các vấn đề và giải pháp
Tuy nhiên, việc sử dụng toán tử sớm bộc lộ một số nhược điểm đáng kể:
- thiếu hỗ trợ nodeSelector;
- không có khả năng vô hiệu hóa các bản sao lưu;
- khi sử dụng chức năng tạo cơ sở dữ liệu, các đặc quyền mặc định không xuất hiện;
- Định kỳ, tài liệu bị thiếu hoặc lỗi thời.
May mắn thay, nhiều trong số đó có thể được giải quyết. Hãy bắt đầu từ cuối - vấn đề với tài liệu.
Rất có thể, bạn sẽ gặp phải thực tế là không phải lúc nào cũng rõ ràng về cách đăng ký bản sao lưu và cách kết nối nhóm dự phòng với Giao diện người dùng của người vận hành. Tài liệu nói sơ qua về điều này, nhưng mô tả thực sự thì có trong :
- cần phải làm một bí mật;
- chuyển nó cho toán tử dưới dạng tham số
pod_environment_secret_nametrong CRD với cài đặt toán tử hoặc trong ConfigMap (tùy thuộc vào cách bạn quyết định cài đặt toán tử).
Tuy nhiên, hóa ra, điều này hiện là không thể. Đó là lý do tại sao chúng tôi đã thu thập với một số phát triển bổ sung của bên thứ ba. Để biết thêm thông tin về nó, xem bên dưới.
Nếu bạn chuyển các tham số để sao lưu cho toán tử, cụ thể là - wal_s3_bucket và các khóa truy cập trong AWS S3, thì nó sẽ sao lưu mọi thứ: không chỉ có cơ sở sản xuất mà còn có cả dàn dựng. Điều này không phù hợp với chúng tôi.
Trong phần mô tả các tham số cho Spilo, trình bao bọc Docker cơ bản cho PGSQL khi sử dụng toán tử, hóa ra: bạn có thể truyền một tham số WAL_S3_BUCKET trống, do đó vô hiệu hóa các bản sao lưu. Hơn nữa, tôi vô cùng vui mừng khi tìm thấy , mà chúng tôi ngay lập tức chấp nhận vào fork của mình. Bây giờ bạn chỉ cần thêm enableWALArchiving: false vào tài nguyên cụm PostgreSQL.
Có, đã có cơ hội để thực hiện điều đó một cách khác biệt bằng cách chạy 2 toán tử: một cho giai đoạn chạy (không có bản sao lưu) và thứ hai cho sản xuất. Nhưng chúng tôi đã có thể làm được với một.
Được rồi, chúng tôi đã học cách chuyển quyền truy cập vào cơ sở dữ liệu cho S3 và các bản sao lưu bắt đầu được đưa vào bộ lưu trữ. Làm cách nào để các trang sao lưu hoạt động trong Giao diện người dùng của người vận hành?
Bạn sẽ cần thêm 3 biến vào Giao diện người dùng của người vận hành:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Sau đó, tính năng quản lý các bản sao lưu sẽ khả dụng, trong trường hợp của chúng tôi sẽ đơn giản hóa công việc với giai đoạn, cho phép chúng tôi phân phối các lát cắt từ quá trình sản xuất ở đó mà không cần thêm tập lệnh.
Một ưu điểm khác là hoạt động với API Teams và có nhiều cơ hội để tạo cơ sở dữ liệu và vai trò bằng các công cụ vận hành. Tuy nhiên, việc tạo ra vai trò không có quyền theo mặc định. Theo đó, người dùng có quyền đọc không thể đọc bảng mới.
Tại sao vậy? Mặc dù thực tế là trong mã sự cần thiết GRANT, chúng không phải lúc nào cũng được sử dụng. Có 2 phương pháp: syncPreparedDatabases и syncDatabases. Trong syncPreparedDatabases - mặc dù thực tế là trong phần preparedDatabases có một điều kiện defaultRoles и defaultUsers để tạo vai trò, quyền mặc định không được áp dụng. Chúng tôi đang trong quá trình chuẩn bị một bản vá để các quyền này được tự động áp dụng.
Và điểm cuối cùng trong những cải tiến có liên quan đến chúng tôi - , bổ sung Mối quan hệ nút vào StatefulSet đã tạo. Khách hàng của chúng tôi thường muốn giảm chi phí bằng cách sử dụng các phiên bản giao ngay và rõ ràng là chúng không đáng để lưu trữ các dịch vụ cơ sở dữ liệu. Vấn đề này có thể được giải quyết thông qua dung sai, nhưng sự hiện diện của Nút ái lực mang lại độ tin cậy cao hơn.
Chuyện gì vậy?
Dựa trên kết quả giải quyết các vấn đề trên, chúng tôi đã fork Postgres Operator từ Zalando thành , nơi nó được thu thập với các bản vá hữu ích như vậy. Và để thuận tiện hơn, chúng tôi cũng thu thập .
Danh sách PR được chấp nhận vào fork:
- ;
- ;
- ;
- .
Sẽ thật tuyệt nếu cộng đồng hỗ trợ các PR này để chúng có thể ngược dòng với phiên bản tiếp theo của nhà điều hành (1.6).
Thưởng! Câu chuyện thành công về di chuyển sản xuất
Nếu bạn sử dụng Patroni, hoạt động sản xuất trực tiếp có thể được di chuyển sang nhà điều hành với thời gian ngừng hoạt động ở mức tối thiểu.
Spilo cho phép bạn tạo các cụm dự phòng thông qua bộ lưu trữ S3 với , khi nhật ký nhị phân PGSQL lần đầu tiên được lưu trữ trong S3 và sau đó được bản sao bơm ra. Nhưng phải làm gì nếu bạn có không được Wal-E sử dụng trên cơ sở hạ tầng cũ? Giải pháp cho vấn đề này đã có rồi trên trung tâm.
Bản sao logic PostgreSQL ra đời để giải cứu. Tuy nhiên, chúng tôi sẽ không đi sâu vào chi tiết về cách tạo ấn phẩm và đăng ký dài hạn vì... kế hoạch của chúng tôi đã thất bại.
Thực tế là cơ sở dữ liệu có một số bảng được tải với hàng triệu hàng, hơn nữa, các bảng này liên tục được bổ sung và xóa. с copy_data, khi bản sao mới sao chép tất cả nội dung từ bản gốc, nó chỉ đơn giản là không thể theo kịp bản gốc. Sao chép nội dung đã hoạt động được một tuần nhưng không bao giờ theo kịp chủ. Cuối cùng, nó đã giúp tôi giải quyết vấn đề đồng nghiệp từ Avito: bạn có thể truyền dữ liệu bằng cách sử dụng pg_dump. Tôi sẽ mô tả phiên bản (được sửa đổi một chút) của thuật toán này.
Ý tưởng là bạn có thể tạo một đăng ký bị vô hiệu hóa gắn với một vị trí sao chép cụ thể, sau đó sửa số giao dịch. Đã có sẵn bản sao cho công việc sản xuất. Điều này rất quan trọng vì bản sao sẽ giúp tạo kết xuất nhất quán và tiếp tục nhận các thay đổi từ bản gốc.
Các lệnh tiếp theo mô tả quá trình di chuyển sẽ sử dụng các ký hiệu máy chủ sau:
- chủ — máy chủ nguồn;
- bản sao1 — phát trực tuyến bản sao trên sản phẩm cũ;
- bản sao2 - bản sao logic mới.
kế hoạch di chuyển
1. Tạo đăng ký trên bản gốc cho tất cả các bảng trong lược đồ public căn cứ dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Tạo một khe sao chép trên bản gốc:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Dừng sao chép trên bản sao cũ:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Lấy số giao dịch từ chủ:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Xóa kết xuất khỏi bản sao cũ. Chúng tôi sẽ thực hiện việc này trong một số chủ đề, điều này sẽ giúp tăng tốc quá trình:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Tải kết xuất lên máy chủ mới:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Sau khi tải xuống kết xuất, bạn có thể bắt đầu sao chép trên bản sao phát trực tuyến:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Hãy tạo đăng ký trên một bản sao logic mới:
psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"
8. Hãy bắt đầu nào oid đăng ký:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Giả sử nó đã được nhận oid=1000. Hãy áp dụng số giao dịch cho đăng ký:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Hãy bắt đầu sao chép:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Kiểm tra trạng thái đăng ký, bản sao sẽ hoạt động:
psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"
12. Sau khi bắt đầu sao chép và cơ sở dữ liệu được đồng bộ hóa, bạn có thể chuyển đổi.
13. Sau khi vô hiệu hóa tính năng sao chép, bạn cần sửa lại trình tự. Điều này được mô tả tốt .
Nhờ kế hoạch này, việc chuyển đổi đã diễn ra với độ trễ tối thiểu.
Kết luận
Toán tử Kubernetes cho phép bạn đơn giản hóa các hành động khác nhau bằng cách giảm chúng xuống việc tạo tài nguyên K8. Tuy nhiên, sau khi đạt được khả năng tự động hóa đáng chú ý với sự trợ giúp của họ, cần nhớ rằng nó cũng có thể mang lại một số sắc thái bất ngờ, vì vậy hãy chọn người vận hành của bạn một cách khôn ngoan.
Sau khi xem xét ba toán tử Kubernetes phổ biến nhất cho PostgreSQL, chúng tôi đã chọn dự án từ Zalando. Và chúng tôi đã phải vượt qua một số khó khăn nhất định với nó, nhưng kết quả thực sự rất hài lòng, vì vậy chúng tôi dự định mở rộng trải nghiệm này sang một số bản cài đặt PGSQL khác. Nếu bạn có kinh nghiệm sử dụng các giải pháp tương tự, chúng tôi sẽ rất vui khi xem chi tiết trong phần bình luận!
PS
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «'.
Nguồn: www.habr.com