Vào cuối năm ngoái, một buổi phát sóng trực tiếp khác của cộng đồng PostgreSQL Nga đã diễn ra , trong đó người đồng sáng lập Nikolai Samokhvalov đã nói chuyện với giám đốc kỹ thuật của Flant, Dmitry Stolyarov về DBMS này trong bối cảnh Kubernetes.
Chúng tôi đang xuất bản bản ghi lại phần chính của cuộc thảo luận này và tại Video đầy đủ được đăng:
Cơ sở dữ liệu và Kubernetes
NS: Hôm nay chúng ta sẽ không nói về VACUUM và CHECKPOINT. Chúng tôi muốn nói về Kubernetes. Tôi biết bạn có nhiều năm kinh nghiệm. Tôi đã xem video của bạn và thậm chí xem lại một số video trong số đó... Hãy đi thẳng vào vấn đề: tại sao lại là Postgres hay MySQL trong K8s?
DS: Không có và không thể có câu trả lời chắc chắn cho câu hỏi này. Nhưng nhìn chung, đây là sự đơn giản và tiện lợi… tiềm năng. Mọi người đều muốn các dịch vụ được quản lý.
NS: Làm thế nào , Chỉ ở nhà?
DS: Có: giống như RDS, ở mọi nơi.
NS: “Bất cứ nơi nào” là một điểm tốt. Trong các công ty lớn, mọi thứ đều được đặt ở những nơi khác nhau. Tại sao, nếu đó là một công ty lớn, lại không áp dụng giải pháp làm sẵn? Ví dụ: Nutanix có những phát triển riêng, các công ty khác (VMware...) cũng có “RDS, only at home”.
DS: Nhưng chúng ta đang nói về một cách triển khai riêng biệt sẽ chỉ hoạt động trong một số điều kiện nhất định. Và nếu chúng ta đang nói về Kubernetes, thì có rất nhiều cơ sở hạ tầng (có thể ở K8). Về cơ bản, đây là tiêu chuẩn dành cho API trên đám mây...
NS: Nó cũng miễn phí!
DS: Nó không quá quan trọng. Sự tự do là quan trọng đối với một phân khúc thị trường không quá lớn. Có điều gì đó quan trọng hơn... Chắc bạn còn nhớ bản báo cáo “»
NS: Đúng.
DS: Tôi nhận ra rằng nó được tiếp nhận rất mơ hồ. Một số người nghĩ rằng tôi đang nói: “Các bạn, hãy đưa tất cả cơ sở dữ liệu vào Kubernetes!”, trong khi những người khác lại cho rằng đây đều là những chiếc xe đạp khủng khiếp. Nhưng tôi muốn nói điều gì đó hoàn toàn khác: “Hãy nhìn xem chuyện gì đang xảy ra, có những vấn đề gì và chúng có thể được giải quyết như thế nào. Chúng ta có nên sử dụng cơ sở dữ liệu Kubernetes bây giờ không? Sản xuất? Chà, chỉ khi bạn thích...làm những việc nhất định. Nhưng đối với một nhà phát triển, tôi có thể nói rằng tôi khuyên bạn nên dùng nó. Đối với một nhà phát triển, tính năng động của việc tạo/xóa môi trường là rất quan trọng.”
NS: Khi nói đến dev, ý bạn là tất cả các môi trường không hỗ trợ phải không? Dàn dựng, QA…
DS: Nếu chúng ta đang nói về giá biểu diễn thì có lẽ là không, vì các yêu cầu ở đó rất cụ thể. Nếu chúng ta đang nói về những trường hợp đặc biệt khi cần một cơ sở dữ liệu rất lớn để dàn dựng thì có lẽ là không... Nếu đây là một môi trường tĩnh, tồn tại lâu dài thì lợi ích của việc đặt cơ sở dữ liệu trong K8 là gì?
NS: Không có. Nhưng chúng ta thấy môi trường tĩnh ở đâu? Một môi trường tĩnh sẽ trở nên lỗi thời vào ngày mai.
DS: Dàn dựng có thể ở trạng thái tĩnh. Chúng tôi có khách hàng...
NS: Vâng, tôi cũng có một cái. Đó là một vấn đề lớn nếu bạn có cơ sở dữ liệu 10 TB và dàn 200 GB...
DS: Tôi có một trường hợp rất hay! Khi dàn dựng có cơ sở dữ liệu sản phẩm để thực hiện các thay đổi. Và có một nút: “triển khai sản xuất”. Những thay đổi này - delta - được thêm vào (có vẻ như chúng được đồng bộ hóa đơn giản thông qua API) trong quá trình sản xuất. Đây là một lựa chọn rất kỳ lạ.
NS: Tôi đã thấy các công ty khởi nghiệp ở Thung lũng đang ngồi trong RDS hoặc thậm chí ở Heroku - đây là những câu chuyện từ 2-3 năm trước - và họ tải kết xuất xuống máy tính xách tay của họ. Bởi vì cơ sở dữ liệu vẫn chỉ có 80 GB và còn trống trên máy tính xách tay. Sau đó, họ mua thêm đĩa cho mọi người để có 3 cơ sở dữ liệu để thực hiện các bước phát triển khác nhau. Đây cũng là cách nó xảy ra. Tôi cũng thấy họ không ngại sao chép sản phẩm vào dàn dựng - điều đó phụ thuộc rất nhiều vào công ty. Nhưng tôi cũng thấy họ rất sợ hãi và thường không có đủ thời gian và sức lực. Nhưng trước khi chuyển sang chủ đề này, tôi muốn nghe về Kubernetes. Tôi có hiểu chính xác là chưa có ai tham gia không?
DS: Chúng tôi có cơ sở dữ liệu nhỏ trong prod. Chúng ta đang nói về khối lượng hàng chục gigabyte và các dịch vụ không quan trọng mà chúng tôi quá lười để tạo bản sao (và không có nhu cầu như vậy). Và với điều kiện là có bộ lưu trữ bình thường trong Kubernetes. Cơ sở dữ liệu này hoạt động trong một máy ảo - có điều kiện trong VMware, trên hệ thống lưu trữ. Chúng tôi đã đặt nó vào và bây giờ chúng ta có thể chuyển nó từ máy này sang máy khác.
NS: Cơ sở dữ liệu có kích thước này, lên tới 100 GB, có thể được triển khai trong vài phút trên các đĩa tốt và mạng tốt, phải không? Tốc độ 1 GB mỗi giây không còn xa lạ nữa.
DS: Có, đối với hoạt động tuyến tính thì đây không phải là vấn đề.
NS: Được rồi, chúng ta chỉ cần nghĩ về sản phẩm. Và nếu chúng ta đang xem xét Kubernetes cho môi trường không có sản phẩm, chúng ta nên làm gì? Tôi thấy điều đó ở Zalando , trong Giòn , có một số lựa chọn khác. Và có - đây là người bạn tốt của chúng tôi Alvaro đến từ Tây Ban Nha: những gì họ làm về cơ bản không chỉ là và toàn bộ phân phối (), trong đó, ngoài chính Postgres, họ còn quyết định đưa vào một bản sao lưu, proxy Envoy...
DS: Sứ giả để làm gì? Cân bằng lưu lượng truy cập Postgres cụ thể?
NS: Đúng. Nghĩa là, họ coi đó là: nếu bạn sử dụng bản phân phối và kernel Linux, thì PostgreSQL thông thường là kernel và họ muốn tạo một bản phân phối thân thiện với đám mây và chạy trên Kubernetes. Họ tập hợp các thành phần (bản sao lưu, v.v.) và gỡ lỗi để chúng hoạt động tốt.
DS: Rất tuyệt! Về cơ bản đây là phần mềm để tạo Postgres được quản lý của riêng bạn.
NS: Các bản phân phối Linux có những vấn đề muôn thuở: làm thế nào để tạo trình điều khiển để tất cả phần cứng đều được hỗ trợ. Và họ có ý tưởng rằng họ sẽ làm việc trong Kubernetes. Tôi biết rằng gần đây chúng tôi đã thấy trong toán tử Zalando có kết nối với AWS và điều này không còn tốt nữa. Không nên có sự ràng buộc với một cơ sở hạ tầng cụ thể - vậy thì ý nghĩa là gì?
DS: Tôi không biết chính xác Zalando đã gặp phải tình huống nào, nhưng bộ lưu trữ Kubernetes hiện được thực hiện theo cách không thể sao lưu đĩa bằng phương pháp chung. Gần đây trong tiêu chuẩn - trong phiên bản mới nhất — chúng tôi đã tạo ra các ảnh chụp nhanh, nhưng nó được triển khai ở đâu? Thành thật mà nói, mọi thứ vẫn còn quá thô sơ... Chúng tôi đang thử CSI trên AWS, GCE, Azure, vSphere, nhưng ngay khi bạn bắt đầu sử dụng nó, bạn có thể thấy rằng nó vẫn chưa sẵn sàng.
NS: Đó là lý do tại sao đôi khi chúng ta phải dựa vào cơ sở hạ tầng. Tôi nghĩ đây vẫn chỉ là giai đoạn đầu - những nỗi đau ngày càng lớn. Câu hỏi: Bạn có lời khuyên nào dành cho những người mới muốn dùng thử PGSQL trong K8s? Nhà điều hành có thể là gì?
DS: Vấn đề là Postgres dành cho chúng tôi 3%. Chúng tôi cũng có một danh sách rất lớn các phần mềm khác nhau trong Kubernetes, tôi thậm chí sẽ không liệt kê mọi thứ. Ví dụ: Elaticsearch. Có rất nhiều nhà khai thác: một số đang tích cực phát triển, số khác thì không. Chúng tôi đã tự đưa ra những yêu cầu về những gì một nhà điều hành phải có để chúng tôi thực hiện nghiêm túc. Trong một toán tử dành riêng cho Kubernetes - không phải trong “toán tử để làm điều gì đó trong điều kiện của Amazon”... Trên thực tế, chúng tôi khá rộng rãi (= hầu hết tất cả khách hàng) sử dụng một toán tử duy nhất - (chúng tôi sẽ sớm xuất bản một bài viết về anh ấy).
NS: Và cũng không dành cho MySQL? Tôi biết rằng Percona... vì họ hiện đang làm việc trên MySQL, MongoDB và Postgres, nên họ sẽ phải tạo ra một số loại giải pháp phổ quát: cho tất cả cơ sở dữ liệu, cho tất cả các nhà cung cấp đám mây.
DS: Chúng tôi không có thời gian để xem xét các toán tử của MySQL. Đây không phải là trọng tâm chính của chúng tôi ngay bây giờ. MySQL hoạt động tốt ở chế độ độc lập. Tại sao phải sử dụng toán tử nếu bạn chỉ có thể khởi chạy cơ sở dữ liệu... Bạn có thể khởi chạy bộ chứa Docker bằng Postrges hoặc bạn có thể khởi chạy nó một cách đơn giản.
NS: Cũng có một câu hỏi về điều này. Không có nhà điều hành nào cả?
DS: Có, 100% chúng tôi chạy PostgreSQL mà không cần người vận hành. Cho đến nay rất. Chúng tôi tích cực sử dụng toán tử cho Prometheus và Redis. Chúng tôi có kế hoạch tìm một nhà điều hành cho Elaticsearch - đó là nhà điều hành “bùng cháy” nhất, bởi vì chúng tôi muốn cài đặt nó trong Kubernetes trong 100% trường hợp. Cũng như chúng tôi muốn đảm bảo rằng MongoDB cũng luôn được cài đặt trong Kubernetes. Ở đây xuất hiện những mong muốn nhất định - có cảm giác rằng trong những trường hợp này có thể làm được điều gì đó. Và chúng tôi thậm chí còn không nhìn vào Postgres. Tất nhiên, chúng tôi biết rằng có nhiều lựa chọn khác nhau, nhưng trên thực tế, chúng tôi có một lựa chọn độc lập.
DB để thử nghiệm trong Kubernetes
NS: Hãy chuyển sang chủ đề kiểm tra. Cách triển khai các thay đổi đối với cơ sở dữ liệu - từ góc độ DevOps. Có các dịch vụ vi mô, nhiều cơ sở dữ liệu, có thứ gì đó luôn thay đổi ở đâu đó. Cách đảm bảo CI/CD bình thường để mọi thứ đều theo thứ tự từ góc độ DBMS. Cách tiếp cận của bạn là gì?
DS: Không thể có một câu trả lời. Có một số lựa chọn. Đầu tiên là kích thước của đế mà chúng tôi muốn triển khai. Bản thân bạn đã đề cập rằng các công ty có thái độ khác nhau đối với việc có một bản sao của cơ sở dữ liệu sản phẩm trên nhà phát triển và sân khấu.
NS: Và theo các điều kiện của GDPR, tôi nghĩ họ ngày càng cẩn thận hơn... Tôi có thể nói rằng ở Châu Âu, họ đã bắt đầu áp dụng tiền phạt.
DS: Nhưng thường thì bạn có thể viết phần mềm lấy kết xuất từ quá trình sản xuất và làm xáo trộn nó. Dữ liệu sản phẩm được lấy (ảnh chụp nhanh, kết xuất, bản sao nhị phân ...), nhưng nó được ẩn danh. Thay vào đó, có thể có các tập lệnh tạo: đây có thể là các tập lệnh cố định hoặc chỉ là tập lệnh tạo ra cơ sở dữ liệu lớn. Vấn đề là: mất bao lâu để tạo ra một hình ảnh cơ bản? Và mất bao lâu để triển khai nó trong môi trường mong muốn?
Chúng tôi đã đi đến một kế hoạch: nếu máy khách có một tập dữ liệu cố định (phiên bản tối thiểu của cơ sở dữ liệu), thì chúng tôi sẽ sử dụng chúng theo mặc định. Nếu chúng ta đang nói về môi trường đánh giá, khi tạo một nhánh, chúng tôi đã triển khai một phiên bản của ứng dụng - chúng tôi triển khai một cơ sở dữ liệu nhỏ ở đó. Nhưng hóa ra lại tốt , khi chúng tôi kết xuất dữ liệu sản xuất mỗi ngày một lần (vào ban đêm) và xây dựng vùng chứa Docker với PostgreSQL và MySQL với dữ liệu được tải này dựa trên nó. Nếu bạn cần mở rộng cơ sở dữ liệu 50 lần từ hình ảnh này thì việc này được thực hiện khá đơn giản và nhanh chóng.
NS: Bằng cách sao chép đơn giản?
DS: Dữ liệu được lưu trữ trực tiếp trong Docker image. Những thứ kia. Chúng tôi có một hình ảnh làm sẵn, mặc dù 100 GB. Nhờ các lớp trong Docker, chúng ta có thể nhanh chóng triển khai hình ảnh này bao nhiêu lần tùy ý. Phương pháp này thật ngu ngốc, nhưng nó hoạt động tốt.
NS: Sau đó, khi bạn kiểm tra, nó sẽ thay đổi ngay trong Docker phải không? Sao chép khi ghi bên trong Docker - vứt nó đi và sử dụng lại, mọi thứ đều ổn. Lớp học! Và bạn đã sử dụng nó một cách tối đa chưa?
DS: Trong một khoảng thời gian dài.
NS: Chúng tôi làm những việc rất giống nhau. Chỉ có điều chúng tôi không sử dụng tính năng sao chép khi ghi của Docker mà sử dụng một số tính năng khác.
DS: Nó không chung chung. Và Docker hoạt động ở mọi nơi.
NS: Về lý thuyết là có. Nhưng chúng tôi cũng có các mô-đun ở đó, bạn có thể tạo các mô-đun khác nhau và làm việc với các hệ thống tệp khác nhau. Thật là một khoảnh khắc ở đây. Từ phía Postgres, chúng tôi nhìn nhận tất cả những điều này một cách khác. Bây giờ tôi nhìn từ phía Docker và thấy rằng mọi thứ đều phù hợp với bạn. Nhưng nếu cơ sở dữ liệu lớn, chẳng hạn như 1 TB, thì tất cả những việc này sẽ mất nhiều thời gian: hoạt động vào ban đêm và nhét mọi thứ vào Docker... Và nếu 5 TB được nhét vào Docker... Hay mọi thứ vẫn ổn?
DS: Sự khác biệt là gì: đây là những đốm màu, chỉ là bit và byte.
NS: Sự khác biệt là thế này: bạn có thực hiện việc đó thông qua kết xuất và khôi phục không?
DS: Không cần thiết chút nào. Các phương pháp tạo hình ảnh này có thể khác nhau.
NS: Đối với một số khách hàng, chúng tôi đã làm điều đó để thay vì thường xuyên tạo hình ảnh cơ sở, chúng tôi liên tục cập nhật nó. Về cơ bản, nó là một bản sao, nhưng nó nhận dữ liệu không trực tiếp từ bản gốc mà thông qua một kho lưu trữ. Một kho lưu trữ nhị phân nơi các WAL được tải xuống hàng ngày, nơi thực hiện các bản sao lưu... Những WAL này sau đó sẽ đến hình ảnh cơ sở với độ trễ nhẹ (nghĩa đen là 1-2 giây). Chúng tôi sao chép nó theo bất kỳ cách nào - bây giờ chúng tôi có ZFS theo mặc định.
DS: Nhưng với ZFS, bạn bị giới hạn ở một nút.
NS: Đúng. Nhưng ZFS cũng có một điều kỳ diệu : với nó, bạn có thể gửi một ảnh chụp nhanh và thậm chí (tôi chưa thực sự thử nghiệm điều này, nhưng...) bạn có thể gửi một delta giữa hai PGDATA. Trên thực tế, chúng tôi có một công cụ khác mà chúng tôi chưa thực sự cân nhắc cho những nhiệm vụ như vậy. PostgreSQL có , hoạt động giống như một rsync “thông minh”, bỏ qua rất nhiều nội dung bạn không cần phải xem vì không có gì thay đổi ở đó. Chúng ta có thể thực hiện đồng bộ hóa nhanh chóng giữa hai máy chủ và tua lại theo cách tương tự.
Vì vậy, từ khía cạnh DBA này, chúng tôi đang cố gắng tạo ra một công cụ cho phép chúng tôi làm điều tương tự như bạn đã nói: chúng tôi có một cơ sở dữ liệu, nhưng chúng tôi muốn kiểm tra thứ gì đó 50 lần, gần như đồng thời.
DS: 50 lần nghĩa là bạn cần đặt mua 50 phiên bản Spot.
NS: Không, chúng tôi làm mọi thứ trên một máy.
DS: Nhưng làm thế nào bạn có thể mở rộng gấp 50 lần nếu cơ sở dữ liệu này có dung lượng lên tới terabyte. Rất có thể cô ấy cần RAM 256 GB có điều kiện?
NS: Có, đôi khi bạn cần nhiều bộ nhớ - điều đó là bình thường. Nhưng đây là một ví dụ từ cuộc sống. Máy sản xuất có 96 lõi và 600 GB. Đồng thời, 32 lõi (đôi khi thậm chí là 16 lõi) và bộ nhớ 100-120 GB được sử dụng cho cơ sở dữ liệu.
DS: Và 50 bản có vừa trong đó không?
NS: Vậy là chỉ có một bản sao thôi, sau đó copy-on-write (ZFS) hoạt động... Tôi sẽ kể chi tiết hơn cho bạn.
Ví dụ: chúng tôi có cơ sở dữ liệu 10 TB. Họ đã tạo một đĩa cho nó, ZFS cũng nén kích thước của nó xuống 30-40%. Vì chúng tôi không thực hiện kiểm tra tải nên thời gian phản hồi chính xác không quan trọng đối với chúng tôi: hãy để tốc độ phản hồi chậm hơn tới 2 lần - không sao cả.
Chúng tôi trao cơ hội cho các lập trình viên, QA, DBA, v.v. thực hiện kiểm tra trong 1-2 chủ đề. Ví dụ: họ có thể thực hiện một số loại di chuyển. Nó không yêu cầu 10 lõi cùng một lúc - nó cần 1 phần phụ trợ Postgres, 1 lõi. Quá trình di chuyển sẽ bắt đầu - có thể vẫn sẽ bắt đầu, khi đó lõi thứ hai sẽ được sử dụng. Chúng tôi có 16-32 lõi được phân bổ nên 10 người có thể làm việc cùng lúc, không vấn đề gì.
Bởi vì về mặt thể chất PGDATA Tương tự, hóa ra chúng tôi thực sự đang lừa dối Postgres. Bí quyết là thế này: ví dụ: 10 Postgres được khởi chạy đồng thời. Vấn đề thường là gì? Họ đặt , giả sử là 25%. Theo đó, đây là 200 GB. Bạn sẽ không thể khởi chạy nhiều hơn ba trong số này vì bộ nhớ sẽ hết.
Nhưng đến một lúc nào đó, chúng tôi nhận ra rằng điều này là không cần thiết: chúng tôi đặt Shared_buffers thành 2 GB. PostgreSQL có và trên thực tế nó là yếu tố duy nhất ảnh hưởng . Chúng tôi đặt nó ở mức 0,5 TB. Và việc chúng không thực sự tồn tại cũng không thành vấn đề: anh ấy lập kế hoạch như thể chúng tồn tại.
Theo đó, khi chúng tôi thử nghiệm một số loại di chuyển, chúng tôi có thể thu thập tất cả các kế hoạch - chúng tôi sẽ xem nó sẽ diễn ra như thế nào trong quá trình sản xuất. Các giây ở đó sẽ khác nhau (chậm hơn), nhưng dữ liệu mà chúng ta thực sự đọc và bản thân các kế hoạch (có những gì THAM GIA, v.v.) hóa ra giống hệt như trong sản xuất. Và bạn có thể chạy song song nhiều bước kiểm tra như vậy trên một máy.
DS: Bạn không nghĩ rằng có một vài vấn đề ở đây sao? Đầu tiên là giải pháp chỉ hoạt động trên PostgreSQL. Cách tiếp cận này rất riêng tư, nó không chung chung. Thứ hai là Kubernetes (và mọi thứ mà công nghệ đám mây hiện nay đang hướng tới) liên quan đến nhiều nút và những nút này chỉ là phù du. Và trong trường hợp của bạn, nó là một nút có trạng thái và liên tục. Những điều này khiến tôi mâu thuẫn.
NS: Đầu tiên, tôi đồng ý, đây hoàn toàn là một câu chuyện của Postgres. Tôi nghĩ nếu chúng ta có một số loại IO trực tiếp và vùng đệm cho gần như toàn bộ bộ nhớ, thì cách tiếp cận này sẽ không hiệu quả - các kế hoạch sẽ khác. Nhưng hiện tại chúng tôi chỉ làm việc với Postgres, chúng tôi không nghĩ đến người khác.
Giới thiệu về Kubernetes. Chính bạn nói với chúng tôi ở khắp mọi nơi rằng chúng tôi có một cơ sở dữ liệu liên tục. Nếu phiên bản không thành công, điều chính là lưu đĩa. Ở đây chúng tôi cũng có toàn bộ nền tảng trong Kubernetes và thành phần với Postgres là riêng biệt (mặc dù một ngày nào đó nó sẽ có ở đó). Do đó, mọi thứ diễn ra như sau: phiên bản bị hỏng, nhưng chúng tôi đã lưu PV của nó và chỉ kết nối nó với một phiên bản (mới) khác, như thể không có chuyện gì xảy ra.
DS: Theo quan điểm của tôi, chúng tôi tạo các nhóm trong Kubernetes. K8s - co giãn: các nút thắt được sắp xếp theo nhu cầu. Nhiệm vụ chỉ đơn giản là tạo một nhóm và nói rằng nó cần lượng tài nguyên X, sau đó K8 sẽ tự tìm ra. Nhưng hỗ trợ lưu trữ trong Kubernetes vẫn chưa ổn định: Trong (bản này đã được phát hành trong tuần trước đây) những tính năng này chỉ trở thành phiên bản beta.
Sáu tháng đến một năm sẽ trôi qua - nó ít nhiều sẽ trở nên ổn định, hoặc ít nhất nó sẽ được tuyên bố như vậy. Sau đó, khả năng chụp ảnh nhanh và thay đổi kích thước sẽ giải quyết hoàn toàn vấn đề của bạn. Bởi vì bạn có một cơ sở. Có, nó có thể không nhanh lắm, nhưng tốc độ phụ thuộc vào những gì “ẩn ý”, bởi vì một số triển khai có thể sao chép và sao chép khi ghi ở cấp hệ thống con đĩa.
NS: Tất cả các công cụ (Amazon, Google...) cũng cần phải bắt đầu hỗ trợ phiên bản này - việc này cũng mất một thời gian.
DS: Chúng tôi chưa sử dụng chúng. Chúng tôi sử dụng của chúng tôi.
Phát triển cục bộ cho Kubernetes
NS: Bạn có từng mong muốn như vậy khi cần cài đặt tất cả các nhóm trên một máy và thực hiện một thử nghiệm nhỏ như vậy không. Để nhanh chóng có được bằng chứng về khái niệm, hãy xem ứng dụng chạy trong Kubernetes mà không cần dành nhiều máy cho nó. Có Minikube phải không?
DS: Đối với tôi, có vẻ như trường hợp này - được triển khai trên một nút - chỉ dành riêng cho việc phát triển cục bộ. Hoặc một số biểu hiện của một mô hình như vậy. Ăn đó , . Chúng tôi đang hướng tới sử dụng Kubernetes IN Docker. Bây giờ chúng tôi bắt đầu làm việc với nó để thử nghiệm.
NS: Tôi từng nghĩ rằng đây là một nỗ lực để gói tất cả các nhóm vào một hình ảnh Docker. Nhưng hóa ra đây là về một cái gì đó hoàn toàn khác. Dù sao, có các thùng chứa riêng biệt, các nhóm riêng biệt - chỉ trong Docker.
DS: Đúng. Và có một sự bắt chước khá buồn cười được thực hiện, nhưng ý nghĩa là thế này... Chúng tôi có một tiện ích để triển khai - . Chúng tôi muốn biến nó thành một chế độ có điều kiện werf up: “Hãy đưa cho tôi Kubernetes địa phương.” Và sau đó chạy điều kiện ở đó werf follow. Sau đó, nhà phát triển sẽ có thể chỉnh sửa IDE và một quy trình sẽ được khởi chạy trong hệ thống để xem các thay đổi và xây dựng lại hình ảnh, triển khai lại chúng cho K8 cục bộ. Đây là cách chúng tôi muốn cố gắng giải quyết vấn đề phát triển địa phương.
Ảnh chụp nhanh và nhân bản cơ sở dữ liệu trong thực tế của K8
NS: Nếu chúng ta quay lại copy-on-write. Tôi nhận thấy rằng những đám mây cũng có ảnh chụp nhanh. Họ làm việc khác nhau. Ví dụ: trong GCP: bạn có một phiên bản nhiều terabyte ở bờ biển phía đông Hoa Kỳ. Bạn chụp ảnh nhanh định kỳ. Bạn lấy một bản sao của đĩa ở bờ biển phía tây từ một ảnh chụp nhanh - trong vài phút, mọi thứ đã sẵn sàng, nó hoạt động rất nhanh, chỉ cần lấp đầy bộ nhớ đệm vào bộ nhớ. Nhưng những bản sao (ảnh chụp nhanh) này là để 'cung cấp' một tập mới. Điều này thật tuyệt khi bạn cần tạo nhiều phiên bản.
Nhưng đối với các thử nghiệm, đối với tôi, có vẻ như các ảnh chụp nhanh mà bạn nói đến trong Docker hoặc tôi nói đến trong ZFS, btrfs và thậm chí LVM... - chúng cho phép bạn không tạo dữ liệu thực sự mới trên một máy. Trên đám mây, bạn vẫn sẽ thanh toán cho chúng mọi lúc và không phải đợi vài giây mà là vài phút (và trong trường hợp này , có thể là một chiếc đồng hồ).
Thay vào đó, bạn có thể lấy dữ liệu này trong một hoặc hai giây, chạy thử nghiệm và vứt nó đi. Những ảnh chụp nhanh này giải quyết các vấn đề khác nhau. Trong trường hợp đầu tiên - để mở rộng quy mô và nhận bản sao mới, và trong trường hợp thứ hai - để thử nghiệm.
DS: Tôi không đồng ý. Làm cho việc nhân bản khối lượng hoạt động bình thường là nhiệm vụ của đám mây. Tôi chưa xem cách triển khai của họ nhưng tôi biết cách chúng tôi thực hiện trên phần cứng. Chúng tôi có Ceph, nó cho phép mọi khối lượng vật lý () nói nhân bản và nhận được tập thứ hai có cùng đặc điểm trong hàng chục mili giây, 'ami, v.v. Bạn cần hiểu rằng bên trong có một bản sao chép phức tạp. Tại sao đám mây không nên làm như vậy? Tôi chắc chắn họ đang cố gắng làm điều này bằng cách này hay cách khác.
NS: Nhưng họ vẫn sẽ mất vài giây, hàng chục giây để nâng cấp một phiên bản, đưa Docker đến đó, v.v.
DS: Tại sao cần phải nâng cao toàn bộ phiên bản? Chúng tôi có một phiên bản có 32 lõi, 16... và nó có thể vừa với nó - ví dụ: bốn. Khi chúng tôi đặt hàng cái thứ năm, phiên bản đó sẽ được nâng lên và sau đó nó sẽ bị xóa.
NS: Vâng, thật thú vị, Kubernetes hóa ra lại là một câu chuyện khác. Cơ sở dữ liệu của chúng tôi không có trong K8 và chúng tôi có một phiên bản. Nhưng việc nhân bản cơ sở dữ liệu nhiều terabyte chỉ mất không quá hai giây.
DS: Điều đó thật tuyệt. Nhưng quan điểm ban đầu của tôi là đây không phải là một giải pháp chung chung. Vâng, nó rất tuyệt, nhưng nó chỉ phù hợp với Postgres và chỉ trên một nút.
NS: Nó không chỉ phù hợp với Postgres: những kế hoạch này, như tôi đã mô tả, sẽ chỉ hoạt động trong đó. Nhưng nếu chúng tôi không bận tâm về các kế hoạch và chúng tôi chỉ cần tất cả dữ liệu để kiểm tra chức năng thì điều này phù hợp với bất kỳ DBMS nào.
DS: Nhiều năm trước, chúng tôi đã làm điều tương tự trên ảnh chụp nhanh LVM. Đây là một cổ điển. Cách tiếp cận này đã được sử dụng rất tích cực. Các nút trạng thái chỉ là một nỗi đau. Bởi vì bạn không nên đánh rơi chúng, bạn nên luôn nhớ đến chúng...
NS: Bạn có thấy khả năng lai ở đây không? Giả sử trạng thái là một loại nhóm nào đó, nó hoạt động với nhiều người (nhiều người thử nghiệm). Chúng tôi có một tập, nhưng nhờ hệ thống tệp, các bản sao đều cục bộ. Nếu pod rơi nhưng đĩa vẫn còn, pod sẽ nổi lên, đếm thông tin về tất cả các bản sao, nhặt lại mọi thứ và nói: “Đây là các bản sao của bạn đang chạy trên các cổng này, hãy tiếp tục làm việc với chúng”.
DS: Về mặt kỹ thuật, điều này có nghĩa là trong Kubernetes, có một nhóm trong đó chúng tôi chạy nhiều Postgres.
NS: Đúng. Anh ta có một giới hạn: giả sử không quá 10 người làm việc với anh ta cùng một lúc. Nếu bạn cần 20, chúng tôi sẽ ra mắt nhóm thứ hai như vậy. Chúng tôi sẽ sao chép hoàn toàn nó, sau khi nhận được tập đầy đủ thứ hai, nó sẽ có 10 bản sao “mỏng” giống nhau. Bạn không nhìn thấy cơ hội này sao?
DS: Chúng ta cần bổ sung thêm vấn đề bảo mật ở đây. Kiểu tổ chức này ngụ ý rằng nhóm này có các đặc quyền (khả năng) cao, bởi vì nó có thể thực hiện các hoạt động không chuẩn trên hệ thống tệp... Nhưng tôi nhắc lại: Tôi tin rằng trong trung hạn họ sẽ sửa lỗi lưu trữ trong Kubernetes và trong những đám mây họ sẽ sửa toàn bộ câu chuyện bằng nhiều tập - mọi thứ sẽ “hoạt động bình thường”. Sẽ có thay đổi kích thước, nhân bản... Có một tập - chúng tôi nói: “Tạo một tập mới dựa trên đó” và sau một giây rưỡi, chúng tôi sẽ có được thứ mình cần.
NS: Tôi không tin vào một giây rưỡi cho nhiều terabyte. Trên Ceph bạn tự làm điều đó, nhưng bạn nói về những đám mây. Truy cập đám mây, tạo bản sao của ổ EBS nhiều terabyte trên EC2 và xem hiệu suất sẽ như thế nào. Nó sẽ không mất một vài giây. Tôi rất quan tâm đến việc khi nào họ sẽ đạt đến cấp độ này. Tôi hiểu những gì bạn đang nói, nhưng tôi cầu xin sự khác biệt.
DS: Ok, nhưng tôi đã nói là trung hạn chứ không phải ngắn hạn. Nhiều năm.
Giới thiệu về toán tử PostgreSQL từ Zalando
Giữa cuộc họp này, Alexey Klyukin, một cựu nhà phát triển đến từ Zalando, cũng tham gia và nói về lịch sử của toán tử PostgreSQL:
Thật tuyệt khi chủ đề này nói chung được đề cập đến: cả Postgres và Kubernetes. Khi chúng tôi bắt đầu thực hiện nó tại Zalando vào năm 2017, đó là chủ đề mà mọi người đều muốn làm nhưng không ai làm được. Mọi người đều đã có Kubernetes, nhưng khi họ hỏi phải làm gì với cơ sở dữ liệu, ngay cả những người như , người đã giảng về K8, đã nói điều gì đó như thế này:
“Hãy truy cập các dịch vụ được quản lý và sử dụng chúng, không chạy cơ sở dữ liệu trong Kubernetes. Nếu không, chẳng hạn như K8 của bạn sẽ quyết định thực hiện nâng cấp, tắt tất cả các nút và dữ liệu của bạn sẽ bay đi rất xa.”
Chúng tôi quyết định tạo một nhà điều hành, trái với lời khuyên này, sẽ khởi chạy cơ sở dữ liệu Postgres trong Kubernetes. Và chúng tôi có lý do chính đáng - . Đây là quá trình chuyển đổi dự phòng tự động cho PostgreSQL, được thực hiện chính xác, tức là. sử dụng etcd, lãnh sự hoặc ZooKeeper làm nơi lưu trữ thông tin về cụm. Một kho lưu trữ như vậy sẽ cung cấp cho tất cả những ai hỏi, chẳng hạn như người lãnh đạo hiện tại là ai, cùng một thông tin - mặc dù thực tế là chúng tôi đã phân phối mọi thứ - để không có sự phân chia bộ não. Hơn nữa chúng tôi đã có cho anh ấy.
Nhìn chung, nhu cầu tự động chuyển đổi dự phòng của công ty xuất hiện sau khi di chuyển từ trung tâm dữ liệu phần cứng nội bộ sang đám mây. Đám mây dựa trên giải pháp PaaS (Nền tảng dưới dạng dịch vụ) độc quyền. Đó là Nguồn mở, nhưng phải mất rất nhiều công sức để thiết lập và chạy nó. Nó được gọi là .
Ban đầu, không có Kubernetes. Chính xác hơn, khi giải pháp của chúng tôi được triển khai, K8 đã tồn tại nhưng nó quá thô nên không phù hợp để sản xuất. Theo tôi, đó là năm 2015 hoặc 2016. Đến năm 2017, Kubernetes đã ít nhiều trưởng thành nên cần phải di chuyển đến đó.
Và chúng tôi đã có một vùng chứa Docker. Có một PaaS sử dụng Docker. Tại sao không thử K8? Tại sao không viết toán tử của riêng bạn? Murat Kabilov, người đến với chúng tôi từ Avito, đã bắt đầu dự án này như một dự án theo sáng kiến của riêng anh ấy - “để chơi” - và dự án đã “cất cánh”.
Nhưng nói chung, tôi muốn nói về AWS. Tại sao lại có mã liên quan đến AWS trước đây...
Khi chạy một cái gì đó trong Kubernetes, bạn cần hiểu rằng K8 là một công việc đang được tiến hành. Nó không ngừng phát triển, cải tiến và thậm chí có lúc bị phá vỡ. Bạn cần theo dõi chặt chẽ tất cả những thay đổi trong Kubernetes, bạn cần sẵn sàng đi sâu vào nó nếu có điều gì đó xảy ra và tìm hiểu cách nó hoạt động một cách chi tiết - có lẽ nhiều hơn những gì bạn muốn. Về nguyên tắc, điều này áp dụng cho mọi nền tảng mà bạn chạy cơ sở dữ liệu của mình trên đó...
Vì vậy, khi chúng tôi đưa ra tuyên bố, chúng tôi đã để Postgres chạy trên một ổ đĩa bên ngoài (trong trường hợp này là EBS, vì chúng tôi đang làm việc trên AWS). Cơ sở dữ liệu đã phát triển, đến một lúc nào đó cần phải thay đổi kích thước của nó: ví dụ: kích thước ban đầu của EBS là 100 TB, cơ sở dữ liệu đã tăng lên đến mức đó, bây giờ chúng tôi muốn tạo EBS 200 TB. Làm sao? Giả sử bạn có thể thực hiện kết xuất/khôi phục trên một phiên bản mới, nhưng việc này sẽ mất nhiều thời gian và kéo theo thời gian ngừng hoạt động.
Vì vậy, tôi muốn thay đổi kích thước để phóng to phân vùng EBS và sau đó yêu cầu hệ thống tệp sử dụng không gian mới. Và chúng tôi đã làm được nhưng lúc đó Kubernetes chưa có API nào cho thao tác thay đổi kích thước. Vì chúng tôi làm việc trên AWS nên chúng tôi đã viết mã cho API của nó.
Không ai ngăn cản bạn làm điều tương tự cho các nền tảng khác. Không có gợi ý nào trong tuyên bố rằng nó chỉ có thể chạy trên AWS và nó sẽ không hoạt động trên mọi thứ khác. Nói chung, đây là một dự án Nguồn mở: nếu bất kỳ ai muốn tăng tốc độ sử dụng API mới, đều được chào đón. Ăn , yêu cầu kéo - nhóm Zalando cố gắng phản hồi chúng khá nhanh và thăng chức cho nhà điều hành. Theo tôi được biết, dự án tại Google Summer of Code và một số sáng kiến tương tự khác. Zalando đang làm việc rất tích cực về vấn đề này.
Tiền thưởng PS!
Nếu bạn quan tâm đến chủ đề PostgreSQL và Kubernetes, thì cũng xin lưu ý rằng Thứ Ba Postgres tiếp theo diễn ra vào tuần trước, nơi tôi đã nói chuyện với Nikolai Alexander Kukushkin từ Zalando. Video từ nó có sẵn .
PPS
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com