Bằng cách nào đó, trong lịch sử, ngành CNTT được chia thành hai phe có điều kiện vì bất kỳ lý do gì: phe “ủng hộ” và phe “chống đối”. Hơn nữa, chủ đề tranh chấp có thể hoàn toàn tùy tiện. Hệ điều hành nào tốt hơn: Win hay Linux? Trên điện thoại thông minh Android hay iOS? Bạn nên lưu trữ mọi thứ trên đám mây hay đặt nó vào bộ lưu trữ RAID lạnh và đặt các ốc vít vào két an toàn? Người PHP có quyền được gọi là lập trình viên không? Đôi khi, những tranh chấp này chỉ mang tính chất tồn tại và không có cơ sở nào khác ngoài lợi ích thể thao.
Điều đó đã xảy ra khi với sự ra đời của các thùng chứa và tất cả các món ăn được yêu thích này với docker và k8 có điều kiện, các cuộc tranh luận “ủng hộ” và “chống lại” việc sử dụng các khả năng mới trong các lĩnh vực khác nhau của chương trình phụ trợ đã bắt đầu. (Hãy đặt trước rằng mặc dù Kubernetes thường được chỉ định là người điều phối trong cuộc thảo luận này, nhưng việc lựa chọn công cụ cụ thể này không có tầm quan trọng cơ bản. Thay vào đó, bạn có thể thay thế bất kỳ công cụ nào khác có vẻ thuận tiện và quen thuộc nhất với bạn .)
Và có vẻ như đây sẽ chỉ là một tranh chấp đơn giản giữa hai mặt của cùng một đồng xu. Vô nghĩa và tàn nhẫn như cuộc đối đầu vĩnh cửu giữa Win và Linux, trong đó có những con người thích hợp tồn tại ở đâu đó ở giữa. Nhưng trong trường hợp container hóa, không phải mọi thứ đều đơn giản như vậy. Thông thường trong những tranh chấp như vậy không có bên phải, nhưng trong trường hợp “sử dụng” hoặc “không sử dụng” các thùng chứa để lưu trữ cơ sở dữ liệu thì mọi thứ đều đảo lộn. Bởi vì ở một khía cạnh nào đó, cả những người ủng hộ và phản đối cách tiếp cận này đều đúng.
Bên sáng
Lập luận của Light Side có thể được mô tả ngắn gọn bằng một cụm từ: “Xin chào, 2k19 ở ngoài cửa sổ!” Tất nhiên, nghe có vẻ giống chủ nghĩa dân túy, nhưng nếu bạn đi sâu vào tình huống này một cách chi tiết, nó có những ưu điểm. Hãy sắp xếp chúng ra ngay bây giờ.
Giả sử bạn có một dự án web lớn. Ban đầu, nó có thể được xây dựng trên cơ sở cách tiếp cận vi dịch vụ hoặc tại một thời điểm nào đó, nó được phát triển thông qua một con đường tiến hóa - trên thực tế, điều này không quan trọng lắm. Bạn đã phân tán dự án của chúng tôi thành các vi dịch vụ riêng biệt, thiết lập điều phối, cân bằng tải và mở rộng quy mô. Và bây giờ, với lương tâm trong sáng, bạn nhâm nhi ly mojito trên võng trong các hiệu ứng habra thay vì nâng cao các máy chủ đã sập. Nhưng trong mọi hành động bạn phải nhất quán. Rất thường xuyên, chỉ bản thân ứng dụng—mã—được chứa trong vùng chứa. Chúng ta còn có gì ngoài mã?
Đúng vậy, dữ liệu. Trọng tâm của bất kỳ dự án nào là dữ liệu của nó: đây có thể là DBMS điển hình - MySQL, Postgre, MongoDB hoặc bộ lưu trữ được sử dụng để tìm kiếm (ElasticSearch), bộ lưu trữ khóa-giá trị cho bộ nhớ đệm - ví dụ: redis, v.v. Hiện tại chúng tôi chưa làm như vậy chúng ta sẽ nói về các tùy chọn triển khai phụ trợ sai lệch khi cơ sở dữ liệu gặp sự cố do truy vấn được viết kém và thay vào đó, chúng ta sẽ nói về việc đảm bảo khả năng chịu lỗi của chính cơ sở dữ liệu này khi tải máy khách. Rốt cuộc, khi chúng tôi chứa ứng dụng của mình và cho phép nó tự do mở rộng quy mô để xử lý bất kỳ số lượng yêu cầu đến nào, điều này sẽ làm tăng tải trên cơ sở dữ liệu một cách tự nhiên.
Trên thực tế, kênh truy cập cơ sở dữ liệu và máy chủ mà nó chạy trên đó trở thành mũi kim trong phần phụ trợ được đóng gói tuyệt đẹp của chúng tôi. Đồng thời, động lực chính của ảo hóa container là tính di động và linh hoạt của cấu trúc, cho phép chúng tôi tổ chức phân phối tải cao điểm trên toàn bộ cơ sở hạ tầng có sẵn cho chúng tôi một cách hiệu quả nhất có thể. Nghĩa là, nếu chúng ta không chứa và triển khai tất cả các thành phần hiện có của hệ thống trên toàn cụm thì chúng ta đang mắc một sai lầm rất nghiêm trọng.
Sẽ hợp lý hơn nhiều khi phân cụm không chỉ bản thân ứng dụng mà còn cả các dịch vụ chịu trách nhiệm lưu trữ dữ liệu. Bằng cách phân cụm và triển khai các máy chủ web hoạt động độc lập và phân phối tải cho nhau trong k8s, chúng tôi đã giải quyết được vấn đề đồng bộ hóa dữ liệu - các nhận xét tương tự trên các bài đăng, nếu chúng tôi lấy một số nền tảng phương tiện hoặc blog làm ví dụ. Trong mọi trường hợp, chúng tôi có một biểu diễn cơ sở dữ liệu nội bộ, thậm chí là ảo, dưới dạng Dịch vụ bên ngoài. Câu hỏi đặt ra là bản thân cơ sở dữ liệu vẫn chưa được phân cụm - các máy chủ web được triển khai trong khối lấy thông tin về những thay đổi từ cơ sở dữ liệu chiến đấu tĩnh của chúng tôi, cơ sở dữ liệu này quay riêng biệt.
Bạn có cảm nhận được sự bắt kịp không? Chúng tôi sử dụng k8s hoặc Swarm để phân phối tải và tránh làm hỏng máy chủ web chính, nhưng chúng tôi không làm điều này đối với cơ sở dữ liệu. Nhưng nếu cơ sở dữ liệu gặp sự cố thì toàn bộ cơ sở hạ tầng theo cụm của chúng tôi sẽ trở nên vô nghĩa - các trang web trống trả về lỗi truy cập cơ sở dữ liệu có tác dụng gì?
Đó là lý do tại sao cần phải phân cụm không chỉ các máy chủ web như thường lệ mà còn cả cơ sở hạ tầng cơ sở dữ liệu. Chỉ bằng cách này, chúng ta mới có thể đảm bảo một cấu trúc hoạt động hoàn toàn trong một nhóm nhưng đồng thời độc lập với nhau. Hơn nữa, ngay cả khi một nửa số chương trình phụ trợ của chúng tôi “sụp đổ” khi tải, phần còn lại sẽ tồn tại và hệ thống đồng bộ hóa cơ sở dữ liệu với nhau trong cụm cũng như khả năng mở rộng và triển khai không ngừng các cụm mới sẽ giúp nhanh chóng đạt được công suất cần thiết - giá như có giá đỡ trong trung tâm dữ liệu.
Ngoài ra, mô hình cơ sở dữ liệu được phân phối theo cụm cho phép bạn đưa chính cơ sở dữ liệu này đến nơi cần thiết; Nếu chúng ta đang nói về một dịch vụ toàn cầu, thì sẽ khá phi logic khi quay một cụm web ở đâu đó trong khu vực San Francisco, đồng thời gửi các gói khi truy cập cơ sở dữ liệu ở khu vực Moscow và quay lại.
Ngoài ra, việc chứa cơ sở dữ liệu cho phép bạn xây dựng tất cả các thành phần của hệ thống ở cùng mức độ trừu tượng. Do đó, điều này giúp các nhà phát triển có thể quản lý chính hệ thống này trực tiếp từ mã mà không cần sự tham gia tích cực của quản trị viên. Các nhà phát triển nghĩ rằng cần có một DBMS riêng cho dự án con mới - thật dễ dàng! đã viết một tệp yaml, tải nó lên cụm và bạn đã hoàn tất.
Và tất nhiên, hoạt động nội bộ được đơn giản hóa rất nhiều. Nói cho tôi biết, đã bao nhiêu lần bạn nhắm mắt khi có một thành viên mới trong đội nhúng tay vào cơ sở dữ liệu chiến đấu để làm việc? Trên thực tế, cái nào là cái duy nhất bạn có và đang quay ngay bây giờ? Tất nhiên, ở đây tất cả chúng ta đều là người lớn, và ở đâu đó chúng ta có một bản dự phòng mới, và thậm chí xa hơn - đằng sau kệ đựng dưa chuột của bà và ván trượt cũ - một bản dự phòng khác, thậm chí có thể là trong kho lạnh, vì văn phòng của bạn đã từng bị cháy một lần. Nhưng tất cả đều giống nhau, mỗi lần giới thiệu một thành viên mới trong nhóm có quyền truy cập vào cơ sở hạ tầng chiến đấu và tất nhiên, vào cơ sở dữ liệu chiến đấu đều là một nhóm có giá trị đối với mọi người xung quanh. Chà, ai biết anh ta, một người mới, có lẽ anh ta thuận tay? Thật đáng sợ, bạn sẽ đồng ý.
Trên thực tế, việc container hóa và cấu trúc liên kết vật lý phân tán của cơ sở dữ liệu dự án của bạn giúp tránh những khoảnh khắc xác thực như vậy. Không tin tưởng một người mới? ĐƯỢC RỒI! Hãy giao cho anh ấy cụm riêng của anh ấy để làm việc và ngắt kết nối cơ sở dữ liệu khỏi các cụm khác - chỉ đồng bộ hóa bằng cách nhấn thủ công và xoay đồng bộ hai phím (một cho trưởng nhóm, một cho quản trị viên). Và mọi người đều hạnh phúc.
Và bây giờ là lúc trở thành đối thủ của việc phân cụm cơ sở dữ liệu.
Mặt tối
Lập luận tại sao việc chứa cơ sở dữ liệu là không đáng và tiếp tục chạy nó trên một máy chủ trung tâm, chúng tôi sẽ không cúi đầu trước những luận điệu chính thống và những tuyên bố như “ông nội đã chạy cơ sở dữ liệu trên phần cứng, và chúng tôi cũng vậy!” Thay vào đó, hãy thử đưa ra một tình huống trong đó việc vận chuyển bằng container sẽ thực sự mang lại lợi ích hữu hình.
Đồng ý rằng, những dự án thực sự cần đế trong thùng chứa có thể đếm trên đầu ngón tay bởi không phải người vận hành máy phay giỏi nhất. Đối với hầu hết các trường hợp, ngay cả việc sử dụng k8s hoặc bản thân Docker Swarm cũng là dư thừa - những công cụ này thường được sử dụng do sự cường điệu chung của công nghệ và thái độ của “đấng toàn năng” trong con người của giới tính để đẩy mọi thứ vào tầm ngắm. những đám mây và container. Chà, vì bây giờ nó là mốt và ai cũng làm vậy.
Trong ít nhất một nửa trường hợp, việc sử dụng Kubernetis hoặc chỉ Docker trên một dự án là không cần thiết. Vấn đề là không phải tất cả các nhóm hoặc công ty gia công được thuê để duy trì cơ sở hạ tầng của khách hàng đều nhận thức được điều này. Điều tồi tệ hơn là khi các thùng chứa được áp đặt, bởi vì nó sẽ tiêu tốn một lượng tiền nhất định cho khách hàng.
Nhìn chung, có ý kiến cho rằng mafia docker/cube đang đè bẹp những khách hàng thuê ngoài các vấn đề cơ sở hạ tầng này một cách ngu ngốc. Xét cho cùng, để làm việc với các cụm, chúng tôi cần những kỹ sư có khả năng làm việc này và hiểu chung về kiến trúc của giải pháp đã triển khai. Chúng tôi đã từng mô tả trường hợp của mình với ấn phẩm Republic - ở đó chúng tôi đã đào tạo nhóm khách hàng cách làm việc trong thực tế của Kubernetis và mọi người đều hài lòng. Và nó rất tốt. Thông thường, những người triển khai k8s sẽ lấy cơ sở hạ tầng của khách hàng làm con tin - bởi vì bây giờ chỉ họ mới hiểu mọi thứ hoạt động ở đó như thế nào; không có chuyên gia nào đứng về phía khách hàng.
Bây giờ hãy tưởng tượng rằng theo cách này, chúng tôi thuê ngoài không chỉ phần máy chủ web mà còn cả việc bảo trì cơ sở dữ liệu. Chúng ta đã nói rằng BD là trái tim, và việc mất đi trái tim sẽ gây tử vong cho bất kỳ sinh vật sống nào. Tóm lại, triển vọng không phải là tốt nhất. Vì vậy, thay vì cường điệu hóa Kubernetis, nhiều dự án không nên bận tâm đến mức giá thông thường dành cho AWS, điều này sẽ giải quyết tất cả các vấn đề về tải trọng trên trang web/dự án của họ. Nhưng AWS không còn là mốt nữa, và sự phô trương có giá trị hơn tiền bạc - thật không may, trong môi trường CNTT cũng vậy.
ĐƯỢC RỒI. Có lẽ dự án thực sự cần phân cụm, nhưng nếu mọi thứ đều rõ ràng với các ứng dụng không trạng thái, thì làm cách nào chúng ta có thể tổ chức kết nối mạng tốt cho cơ sở dữ liệu được phân cụm?
Nếu chúng ta đang nói về một giải pháp kỹ thuật liền mạch, tức là quá trình chuyển đổi sang k8, thì vấn đề đau đầu chính của chúng ta là sao chép dữ liệu trong cơ sở dữ liệu theo cụm. Một số DBMS ban đầu khá trung thành với việc phân phối dữ liệu giữa các phiên bản riêng lẻ của chúng. Nhiều người khác không được chào đón như vậy. Và thông thường, lập luận chính trong việc chọn DBMS cho dự án của chúng tôi không phải là khả năng nhân rộng với chi phí kỹ thuật và tài nguyên tối thiểu. Đặc biệt nếu dự án ban đầu không được lên kế hoạch như một dịch vụ vi mô mà chỉ đơn giản phát triển theo hướng này.
Chúng tôi nghĩ không cần phải nói về tốc độ của ổ đĩa mạng - chúng chậm. Những thứ kia. Chúng tôi vẫn không có cơ hội thực sự, nếu có điều gì đó xảy ra, để khởi động lại phiên bản DBMS ở nơi có nhiều thứ hơn, chẳng hạn như sức mạnh bộ xử lý hoặc RAM trống. Chúng ta sẽ nhanh chóng xem xét hiệu suất của hệ thống con đĩa ảo hóa. Theo đó, DBMS phải được gắn chặt vào bộ máy riêng của nó được đặt ở gần nhau. Hoặc bằng cách nào đó cần phải hạ nhiệt riêng biệt đồng bộ hóa dữ liệu đủ nhanh cho lượng dự trữ được cho là.
Tiếp tục chủ đề về hệ thống tệp ảo: Thật không may, Docker Volume không phải là không có vấn đề. Nói chung, trong vấn đề lưu trữ dữ liệu đáng tin cậy lâu dài, tôi muốn thực hiện các phương án đơn giản nhất về mặt kỹ thuật. Và việc thêm một lớp trừu tượng mới từ FS của vùng chứa vào FS của máy chủ gốc tự nó đã là một rủi ro. Nhưng khi hoạt động của hệ thống hỗ trợ container hóa cũng gặp khó khăn trong việc truyền tải dữ liệu giữa các lớp này thì đó thực sự là một thảm họa. Hiện tại, hầu hết các vấn đề mà nhân loại tiến bộ biết đến dường như đã được giải quyết. Nhưng bạn hiểu không, cơ chế càng phức tạp thì càng dễ hỏng.
Trước tất cả những “cuộc phiêu lưu” này, việc giữ cơ sở dữ liệu ở một nơi sẽ có lợi hơn và dễ dàng hơn nhiều và ngay cả khi bạn cần chứa ứng dụng, hãy để nó tự chạy và thông qua cổng phân phối, nhận được liên lạc đồng thời với cơ sở dữ liệu, sẽ chỉ được đọc và ghi một lần và ở một nơi. Cách tiếp cận này làm giảm khả năng xảy ra lỗi và mất đồng bộ hóa ở mức tối thiểu.
Chúng ta đang dẫn đến điều gì? Hơn nữa, việc chứa cơ sở dữ liệu là phù hợp khi có nhu cầu thực sự về nó. Bạn không thể nhồi nhét một cơ sở dữ liệu ứng dụng đầy đủ và quay nó như thể bạn có hai tá dịch vụ vi mô - nó không hoạt động theo cách đó. Và điều này phải được hiểu rõ ràng.
Thay vì đầu ra
Nếu bạn đang chờ đợi một kết luận rõ ràng “có ảo hóa cơ sở dữ liệu hay không”, thì chúng tôi sẽ làm bạn thất vọng: nó sẽ không có ở đây. Bởi vì khi tạo ra bất kỳ giải pháp cơ sở hạ tầng nào, người ta không phải được hướng dẫn bởi thời trang và tiến bộ mà trước hết là theo lẽ thường.
Có những dự án mà các nguyên tắc và công cụ đi kèm với Kubernetis hoàn toàn phù hợp và trong những dự án đó, ít nhất có sự yên bình trong khu vực phụ trợ. Và có những dự án không cần container hóa mà là cơ sở hạ tầng máy chủ thông thường, vì về cơ bản chúng không thể thay đổi quy mô sang mô hình cụm microservice, vì chúng sẽ thất bại.
Nguồn: www.habr.com