Triển khai bản sao MySQL Multicloud an toàn trên AWS và GCP với VPN

Tại sao nên chọn MySQL Replication?

Một số điều cơ bản đầu tiên về công nghệ nhân bản. MySQL Replication không phức tạp! Nó dễ dàng thực hiện, giám sát và điều chỉnh vì có nhiều tài nguyên khác nhau mà bạn có thể tận dụng - google là một. MySQL Replication không chứa nhiều biến cấu hình để điều chỉnh. Các lỗi logic của SQL_THREAD và IO_THREAD không khó hiểu và khó sửa. MySQL Replication rất phổ biến hiện nay và cung cấp một cách đơn giản để triển khai cơ sở dữ liệu Tính sẵn sàng cao. Các tính năng mạnh mẽ như GTID (Mã định danh giao dịch toàn cầu) thay vì vị trí nhật ký nhị phân kiểu cũ hoặc Sao chép bán đồng bộ không mất dữ liệu làm cho nó mạnh mẽ hơn.

Như chúng ta đã thấy trong một bài viết trước đó, độ trễ mạng là một thách thức lớn khi lựa chọn một giải pháp có tính khả dụng cao. Sử dụng MySQL Replication mang lại lợi thế là không nhạy cảm với độ trễ. Nó không thực hiện bất kỳ bản sao dựa trên chứng nhận nào, không giống như Galera Cluster sử dụng giao tiếp nhóm và các kỹ thuật đặt hàng giao dịch để đạt được sự nhân rộng đồng bộ. Do đó, không có yêu cầu rằng tất cả các nút phải xác nhận một bộ ghi và không cần đợi trước khi thực hiện một cam kết trên nô lệ hoặc bản sao khác.

Việc chọn Bản sao MySQL truyền thống với phương pháp tiếp cận Sơ cấp-Trung học không đồng bộ cung cấp cho bạn tốc độ khi xử lý các giao dịch từ bên trong tổng thể của bạn; nó không cần đợi các nô lệ đồng bộ hóa hoặc cam kết các giao dịch. Thiết lập thường có một chính (chính) và một hoặc nhiều phụ (nô lệ). Do đó, nó là một hệ thống không chia sẻ, nơi tất cả các máy chủ có bản sao đầy đủ của dữ liệu theo mặc định. Tất nhiên là có mặt hạn chế. Tính toàn vẹn dữ liệu có thể là một vấn đề nếu các nô lệ của bạn không thể sao chép do lỗi chuỗi SQL và I / O hoặc sự cố. Ngoài ra, để giải quyết các vấn đề về tính toàn vẹn của dữ liệu, bạn có thể chọn triển khai MySQL Replication ở dạng bán đồng bộ (hoặc được gọi là sao chép bán đồng bộ không mất dữ liệu trong MySQL 5.7). Điều này hoạt động như thế nào, bản sao phải đợi cho đến khi một bản sao ghi nhận tất cả các sự kiện của giao dịch. Điều này có nghĩa là nó phải hoàn tất quá trình ghi vào nhật ký chuyển tiếp và xả ra đĩa trước khi gửi lại cho cái chính với một phản hồi ACK. Với tính năng sao chép bán đồng bộ được bật, các luồng hoặc phiên trong tổng thể phải đợi xác nhận từ một bản sao. Khi nó nhận được phản hồi ACK từ bản sao, sau đó nó có thể thực hiện giao dịch. Hình minh họa bên dưới cho thấy cách MySQL xử lý sao chép bán đồng bộ.

Với việc triển khai này, tất cả giao dịch đã cam kết đã được sao chép sang ít nhất một nô lệ trong trường hợp có sự cố chính. Mặc dù bán đồng bộ tự nó không phải là một giải pháp có tính khả dụng cao, nhưng nó là một thành phần cho giải pháp của bạn. Tốt nhất là bạn nên biết nhu cầu của mình và điều chỉnh việc triển khai bán đồng bộ hóa của mình cho phù hợp. Do đó, nếu một số mất mát dữ liệu có thể chấp nhận được, thì thay vào đó, bạn có thể sử dụng sao chép không đồng bộ truyền thống.

Bản sao dựa trên GTID rất hữu ích đối với DBA vì nó đơn giản hóa nhiệm vụ thực hiện chuyển đổi dự phòng, đặc biệt khi một nô lệ được trỏ đến một chủ khác hoặc chủ mới. Điều này có nghĩa là với MASTER_AUTO_POSITION =1 đơn giản sau khi thiết lập thông tin xác thực máy chủ lưu trữ và bản sao chính xác, nó sẽ bắt đầu sao chép từ bản chính mà không cần tìm và chỉ định các vị trí x &y nhật ký nhị phân chính xác. Việc bổ sung hỗ trợ sao chép song song cũng tăng cường các luồng nhân bản vì nó tăng thêm tốc độ xử lý các sự kiện từ nhật ký chuyển tiếp.

Do đó, MySQL Replication là một thành phần lựa chọn tuyệt vời hơn các giải pháp HA khác nếu nó phù hợp với nhu cầu của bạn.

Các cấu trúc liên kết cho MySQL Replication

Triển khai MySQL Replication trong môi trường đa đám mây với GCP (Google Cloud Platform) và AWS vẫn là cách tiếp cận tương tự nếu bạn phải sao chép tại chỗ.

Có nhiều cấu trúc liên kết khác nhau mà bạn có thể thiết lập và triển khai.

Master với Slave Replication (Single Replication)

Đây là cấu trúc liên kết sao chép MySQL đơn giản nhất. Một chủ nhận ghi, một hoặc nhiều nô lệ sao chép từ cùng một chủ thông qua sao chép không đồng bộ hoặc bán đồng bộ. Nếu chủ nhân được chỉ định gặp sự cố, nô lệ cập nhật nhất phải được thăng cấp làm chủ nhân mới. Các nô lệ còn lại tiếp tục sao chép từ bản chính mới.

Master with Relay Slaves (Chain Replication)

Thiết lập này sử dụng một master trung gian để hoạt động như một sự chuyển tiếp đến các nô lệ khác trong chuỗi sao chép. Khi có nhiều nô lệ được kết nối với một chủ, giao diện mạng của chủ có thể bị quá tải. Cấu trúc liên kết này cho phép các bản sao đọc để kéo dòng sao chép từ máy chủ chuyển tiếp để giảm tải máy chủ chính. Trên máy chủ chuyển tiếp phụ, phải bật ghi nhật ký nhị phân và log_slave_updates, theo đó các bản cập nhật mà máy chủ phụ nhận được từ máy chủ chính sẽ được ghi vào nhật ký nhị phân của chính nô lệ.

Sử dụng rơle nô lệ có các vấn đề:

• log_slave_updates có một số hình phạt về hiệu suất.
• Độ trễ sao chép trên máy chủ chuyển tiếp phụ sẽ tạo ra độ trễ trên tất cả các nô lệ của nó.
• Các giao dịch giả mạo trên máy chủ chuyển tiếp nô lệ sẽ lây nhiễm cho tất cả các nô lệ của nó.
• Nếu máy chủ chuyển tiếp phụ bị lỗi và bạn không sử dụng GTID, tất cả các nô lệ của nó sẽ ngừng sao chép và chúng cần được khởi động lại.

Master với Active Master (Sao chép vòng tròn)

Còn được gọi là cấu trúc liên kết vòng, thiết lập này yêu cầu hai hoặc nhiều máy chủ MySQL hoạt động như một máy chủ. Tất cả các bản gốc đều nhận được các lần ghi và tạo các binlog với một số lưu ý sau:

• Bạn cần đặt độ lệch tăng tự động trên mỗi máy chủ để tránh xung đột khóa chính.
• Không có cách giải quyết xung đột.
• MySQL Replication hiện không hỗ trợ bất kỳ giao thức khóa nào giữa máy chủ và máy chủ để đảm bảo tính nguyên tử của bản cập nhật phân tán trên hai máy chủ khác nhau.
• Phương pháp phổ biến là chỉ ghi vào một nút chính và nút chính còn lại hoạt động như một nút chờ nóng. Tuy nhiên, nếu bạn có các nô lệ bên dưới cấp đó, bạn phải chuyển sang cấp chính mới theo cách thủ công nếu cấp chính được chỉ định không thành công.
• ClusterControl không hỗ trợ cấu trúc liên kết này (chúng tôi không khuyến khích nhiều người viết trong một thiết lập sao chép). Xem blog trước này về cách triển khai với ClusterControl.

Master với Backup Master (Nhiều bản sao)

Master đẩy các thay đổi đến một master dự phòng và một hoặc nhiều nô lệ. Sao chép bán đồng bộ được sử dụng giữa bản chính và bản sao dự phòng. Master gửi cập nhật đến master backup và đợi với cam kết giao dịch. Sao lưu tổng thể nhận các bản cập nhật, ghi vào nhật ký chuyển tiếp của nó và chuyển vào đĩa. Sau đó, sao lưu master xác nhận đã nhận giao dịch cho master và tiến hành cam kết giao dịch. Sao chép bán đồng bộ có tác động đến hiệu suất, nhưng nguy cơ mất dữ liệu được giảm thiểu.

Cấu trúc liên kết này hoạt động tốt khi thực hiện chuyển đổi dự phòng chính trong trường hợp tổng thể gặp sự cố. Bản sao dự phòng hoạt động như một máy chủ ở chế độ chờ vì nó có xác suất cao nhất để có dữ liệu cập nhật khi so sánh với các máy chủ khác.

Nhiều Master thành Single Slave (Sao chép Đa Nguồn)

Nhân rộng đa nguồn cho phép một nô lệ nhân bản nhận các giao dịch từ nhiều nguồn đồng thời. Sao chép đa nguồn có thể được sử dụng để sao lưu nhiều máy chủ vào một máy chủ duy nhất, để hợp nhất các phân đoạn bảng và hợp nhất dữ liệu từ nhiều máy chủ thành một máy chủ duy nhất.

MySQL và MariaDB có các cách triển khai sao chép đa nguồn khác nhau, trong đó MariaDB phải có GTID với gtid-domain-id được định cấu hình để phân biệt các giao dịch gốc trong khi MySQL sử dụng một kênh sao chép riêng cho từng chủ mà nô lệ sao chép từ đó. Trong MySQL, các bản chính trong cấu trúc liên kết sao chép đa nguồn có thể được định cấu hình để sử dụng bản sao dựa trên mã định danh giao dịch toàn cầu (GTID) hoặc sao chép dựa trên vị trí nhật ký nhị phân.

Có thể tìm thấy thêm về MariaDB sao chép đa nguồn trong bài đăng trên blog này. Đối với MySQL, vui lòng tham khảo tài liệu MySQL.

Galera với Replication Slave (Sao chép hỗn hợp)

Sao chép lai là sự kết hợp của nhân bản không đồng bộ MySQL và nhân bản hầu như đồng bộ do Galera cung cấp. Việc triển khai hiện được đơn giản hóa với việc triển khai GTID trong bản sao MySQL, nơi việc thiết lập và thực hiện chuyển đổi dự phòng chính đã trở thành một quá trình đơn giản ở phía máy chủ.

Hiệu suất của cụm Galera nhanh như nút chậm nhất. Việc có một nô lệ sao chép không đồng bộ có thể giảm thiểu tác động đến cụm nếu bạn gửi các truy vấn loại báo cáo / OLAP dài hạn tới nô lệ hoặc nếu bạn thực hiện các công việc nặng đòi hỏi khóa như mysqldump. Nô lệ cũng có thể đóng vai trò như một bản sao lưu trực tiếp để phục hồi thảm họa tại chỗ và bên ngoài.

Sao chép hỗn hợp được hỗ trợ bởi ClusterControl và bạn có thể triển khai nó trực tiếp từ giao diện người dùng ClusterControl. Để biết thêm thông tin về cách thực hiện việc này, vui lòng đọc các bài đăng trên blog - Sao chép kết hợp với MySQL 5.6 và Nhân bản kết hợp với MariaDB 10.x.

Chuẩn bị nền tảng GCP và AWS

Vấn đề "thế giới thực"

Trong blog này, chúng tôi sẽ trình bày và sử dụng cấu trúc liên kết "Multiple Replication" trong đó các trường hợp trên hai nền tảng đám mây công cộng khác nhau sẽ giao tiếp bằng MySQL Replication trên các vùng khác nhau và trên các vùng khả dụng khác nhau. Kịch bản này dựa trên một vấn đề trong thế giới thực trong đó một tổ chức muốn kiến ​​trúc cơ sở hạ tầng của họ trên nhiều nền tảng đám mây để có khả năng mở rộng, dự phòng, khả năng phục hồi / chịu lỗi. Các khái niệm tương tự sẽ áp dụng cho MongoDB hoặc PostgreSQL.

Hãy xem xét một tổ chức của Hoa Kỳ, có chi nhánh ở nước ngoài ở Đông Nam Á. Lưu lượng truy cập của chúng tôi cao trong khu vực dựa trên Châu Á. Độ trễ phải thấp khi phục vụ cho việc viết và đọc, nhưng đồng thời khu vực có trụ sở tại Hoa Kỳ cũng có thể tăng các bản ghi đến từ lưu lượng truy cập ở Châu Á.

Luồng kiến ​​trúc đám mây

Trong phần này, tôi sẽ thảo luận về thiết kế kiến ​​trúc. Đầu tiên, chúng tôi muốn cung cấp một lớp bảo mật cao mà các nút Google Compute và AWS EC2 của chúng tôi có thể giao tiếp, cập nhật hoặc cài đặt các gói từ internet, an toàn, có tính khả dụng cao trong trường hợp AZ (Vùng khả dụng) gặp sự cố, có thể tái tạo và giao tiếp với một nền tảng đám mây khác qua một lớp bảo mật. Xem hình ảnh minh họa bên dưới:

Dựa trên hình minh họa ở trên, trong nền tảng AWS, tất cả các nút đang chạy trên các vùng khả dụng khác nhau. Nó có một mạng con riêng tư và công khai mà tất cả các nút tính toán đều nằm trên một mạng con riêng. Do đó, nó có thể ra ngoài internet để kéo và cập nhật các gói hệ thống của nó khi cần thiết. Nó có một cổng VPN mà nó phải tương tác với GCP trong kênh đó, bỏ qua Internet nhưng thông qua một kênh riêng tư và an toàn. Tương tự như GCP, tất cả các nút máy tính đều nằm trên các vùng khả dụng khác nhau, sử dụng NAT Gateway để cập nhật gói hệ thống khi cần và sử dụng kết nối VPN để tương tác với các nút AWS được lưu trữ trên một khu vực khác, tức là Châu Á Thái Bình Dương (Singapore). Mặt khác, khu vực có trụ sở tại Hoa Kỳ được đặt dưới quyền sở hữu của chúng tôi ở phía đông1. Để truy cập các nút, một nút trong kiến ​​trúc đóng vai trò là nút cơ sở mà chúng ta sẽ sử dụng nó làm máy chủ lưu trữ nhảy và cài đặt ClusterControl. Điều này sẽ được giải quyết sau trong blog này.

Thiết lập Môi trường GCP và AWS

Khi đăng ký tài khoản GCP đầu tiên của bạn, Google cung cấp tài khoản VPC (Đám mây riêng ảo) mặc định. Do đó, tốt nhất bạn nên tạo một VPC riêng biệt hơn mặc định và tùy chỉnh nó theo nhu cầu của bạn.

Mục tiêu của chúng tôi ở đây là đặt các nút tính toán trong các mạng con riêng tư hoặc các nút sẽ không được thiết lập với IPv4 công cộng. Do đó, cả hai đám mây công cộng phải có thể nói chuyện với nhau. Các nút tính toán AWS và GCP hoạt động với các CIDR khác nhau như đã đề cập trước đây. Do đó, đây là CIDR sau:

Nút tính toán AWS: 172.21.0.0/16
Nút tính toán GCP: 10.142.0.0/20

Trong thiết lập AWS này, chúng tôi đã phân bổ ba mạng con không có Cổng Internet mà là Cổng NAT; và một mạng con có Cổng Internet. Mỗi mạng con này được lưu trữ riêng lẻ ở các Vùng sẵn sàng khác nhau (AZ).

ap-Southeast-1a =172.21.1.0/24
ap-Southeast-1b =172.21.8.0/24
ap-Southeast-1c =172.21.24.0/24

Trong GCP, mạng con mặc định được tạo trong VPC theo us-East1 là 10.142.0.0/20 CIDR được sử dụng. Do đó, đây là các bước bạn có thể làm theo để thiết lập nền tảng đám mây đa công cộng của mình.

• Đối với bài tập này, tôi đã tạo một VPC ở khu vực us-East1 với mạng con 10.142.0.0/20 sau đây. Xem bên dưới:

  

• Đặt trước một IP tĩnh. Đây là IP mà chúng tôi sẽ thiết lập làm Cổng khách hàng trong AWS

  

• Vì chúng tôi có các mạng con tại chỗ (được cấp là subnet-us-west1 ), đi tới GCP -> Mạng VPC -> Mạng VPC và chọn VPC bạn đã tạo và đi tới Quy tắc tường lửa . Trong phần này, hãy thêm các quy tắc bằng cách chỉ định lối vào và lối ra của bạn. Về cơ bản, đây là các quy tắc đến / đi trong AWS hoặc tường lửa của bạn cho các kết nối đến và đi. Trong thiết lập này, tôi đã mở tất cả các giao thức TCP từ phạm vi CIDR được đặt trong AWS và GCP VPC của tôi để làm cho nó đơn giản hơn cho mục đích của blog này. Do đó, đây không phải là cách tối ưu để bảo mật. Xem hình ảnh bên dưới:

  

  Tường lửa-ssh ở đây sẽ được sử dụng để cho phép các kết nối đến ssh, HTTP và HTTPS.

• Bây giờ chuyển sang AWS và tạo VPC. Đối với blog này, tôi đã sử dụng CIDR (Định tuyến liên miền không phân lớp) 172.21.0.0/16

• Tạo các mạng con mà bạn phải gán chúng trong từng AZ (Vùng sẵn sàng); và ít nhất dành một mạng con cho một mạng con công cộng sẽ xử lý NAT Gateway và phần còn lại dành cho các nút EC2.

  

• Tiếp theo, tạo Bảng lộ trình của bạn và đảm bảo rằng "Điểm đến" và "Mục tiêu" được đặt chính xác. Đối với blog này, tôi đã tạo 2 bảng lộ trình. Một cái sẽ xử lý 3 AZ mà các nút máy tính của tôi sẽ được chỉ định riêng lẻ và sẽ được chỉ định mà không có Cổng Internet vì nó sẽ không có IP công cộng. Sau đó, cái còn lại sẽ xử lý NAT Gateway và sẽ có một Internet Gateway nằm trong mạng con công cộng. Xem hình ảnh bên dưới:

  

  và như đã đề cập, điểm đến trong ví dụ của tôi cho tuyến riêng xử lý 3 mạng con cho thấy có mục tiêu NAT Gateway cộng với mục tiêu Virtual Gateway mà tôi sẽ đề cập sau trong các bước sắp tới.

  

• Tiếp theo, tạo một "Cổng Internet" và gán nó cho VPC đã được tạo trước đó trong phần AWS VPC. Cổng Internet này sẽ chỉ được đặt làm điểm đến của mạng con công cộng vì nó sẽ là dịch vụ phải kết nối với internet. Rõ ràng, tên viết tắt của một dịch vụ cổng internet.

• Tiếp theo, tạo một "NAT Gateway". Khi tạo một "NAT Gateway", hãy đảm bảo rằng bạn đã gán NAT của mình cho một mạng con công khai. NAT Gateway là kênh của bạn để truy cập internet từ mạng con riêng tư của bạn hoặc các nút EC2 không được gán IPv4 công khai. Sau đó, tạo hoặc chỉ định một EIP (Elastic IP) vì trong AWS, chỉ các nút tính toán được gán IPv4 công cộng mới có thể kết nối trực tiếp với internet.

• Bây giờ, trong VPC -> Bảo mật -> Nhóm bảo mật (SG) , VPC đã tạo của bạn sẽ có SG mặc định. Đối với thiết lập này, tôi đã tạo "Quy tắc đến" với các nguồn được chỉ định cho từng CIDR, tức là 10.142.0.0/20 trong GCP và 172.21.0.0/16 trong AWS. Xem bên dưới:

  

  Đối với "Quy tắc đi", bạn có thể để nguyên như vậy vì việc gán quy tắc cho "Quy tắc đến" là song phương, có nghĩa là nó cũng sẽ mở cho "Quy tắc đi". Lưu ý rằng đây không phải là cách tối ưu để thiết lập Nhóm bảo mật của bạn; nhưng để giúp việc thiết lập này dễ dàng hơn, tôi cũng đã tạo phạm vi cổng và nguồn rộng hơn. Ngoài ra, giao thức chỉ dành riêng cho các kết nối TCP vì chúng tôi sẽ không xử lý UDP cho blog này.
  Ngoài ra, bạn có thể rời khỏi VPC -> Bảo mật -> ACL mạng của mình > không bị ảnh hưởng miễn là nó KHÔNG TỪ CHỐI bất kỳ kết nối tcp nào từ CIDR được nêu trong nguồn của bạn.

• Tiếp theo, chúng tôi sẽ thiết lập cấu hình VPN sẽ được lưu trữ dưới nền tảng AWS. Trong VPC -> Cổng khách hàng , tạo cổng bằng địa chỉ IP tĩnh đã được tạo trước đó ở bước trước. Hãy xem hình ảnh bên dưới:

  

• Tiếp theo, tạo một Cổng riêng ảo và đính kèm cái này vào VPC hiện tại mà chúng ta đã tạo trước đó ở bước trước. Xem hình ảnh bên dưới:

  

• Bây giờ, hãy tạo một kết nối VPN sẽ được sử dụng cho kết nối giữa các trang web giữa AWS và GCP. Khi tạo kết nối VPN, hãy đảm bảo rằng bạn đã chọn đúng Cổng riêng ảo và Cổng khách hàng mà chúng tôi đã tạo ở các bước trước. Xem hình ảnh bên dưới:

  

  Quá trình này có thể mất một chút thời gian trong khi AWS đang tạo kết nối VPN của bạn. Khi kết nối VPN của bạn sau đó được cấp phép, bạn có thể thắc mắc tại sao trong tab Đường hầm (sau khi bạn chọn kết nối VPN của mình), nó sẽ hiển thị rằng Địa chỉ IP bên ngoài đang giảm. Điều này là bình thường vì chưa có kết nối nào được thiết lập từ máy khách. Hãy xem hình ảnh ví dụ bên dưới:

  

  Khi kết nối VPN đã sẵn sàng, hãy chọn kết nối VPN của bạn đã tạo và tải xuống cấu hình. Nó chứa thông tin đăng nhập của bạn cần thiết cho các bước sau để tạo kết nối VPN site-to-site với máy khách.

  Lưu ý: Trong trường hợp bạn đã thiết lập VPN của mình trong đó IPSEC IS UP nhưng Trạng thái là XUỐNG giống như hình ảnh bên dưới

  

  điều này có thể do các giá trị được đặt sai cho các thông số cụ thể trong khi thiết lập phiên BGP hoặc bộ định tuyến đám mây của bạn. Hãy xem nó tại đây để khắc phục sự cố VPN của bạn.

• Vì chúng tôi đã có sẵn kết nối VPN được lưu trữ trong AWS, nên hãy tạo kết nối VPN trong GCP. Bây giờ, hãy quay lại GCP và thiết lập kết nối máy khách ở đó. Trong GCP, đi tới GCP -> Kết nối kết hợp -> VPN . Đảm bảo rằng bạn đang chọn đúng khu vực, trên blog này, chúng tôi đang sử dụng us-west1 . Sau đó chọn địa chỉ IP tĩnh đã tạo ở các bước trước. Xem hình ảnh bên dưới:

  

  Sau đó, trong Đường hầm , đây là nơi bạn sẽ phải thiết lập dựa trên thông tin đăng nhập đã tải xuống từ kết nối AWS VPN mà bạn đã tạo trước đó. Tôi khuyên bạn nên xem hướng dẫn hữu ích này từ Google. Ví dụ:một trong những đường hầm đang được thiết lập được hiển thị trong hình ảnh bên dưới:

  

  Về cơ bản, những điều quan trọng nhất ở đây là:

  • Cổng ngang hàng từ xa:Địa chỉ IP - Đây là IP của máy chủ VPN được nêu trong Chi tiết đường hầm -> Địa chỉ IP bên ngoài . Điều này không được nhầm lẫn với IP tĩnh mà chúng tôi đã tạo trong GCP. Đó là Cổng VPN đám mây -> Địa chỉ IP mặc dù vậy.
  • Bộ định tuyến đám mây ASN - Theo mặc định, AWS sử dụng 65000. Nhưng có thể, bạn sẽ nhận được thông tin này từ tệp cấu hình đã tải xuống.
  • ASN của bộ định tuyến ngang hàng - Đây là Cổng riêng ảo ASN được tìm thấy trong tệp cấu hình đã tải xuống.
  • Địa chỉ IP BGP của Bộ định tuyến đám mây - Đây là Cổng khách hàng tìm thấy trong tệp cấu hình đã tải xuống.
  • Địa chỉ IP ngang hàng BGP - Đây là Cổng riêng ảo tìm thấy trong tệp cấu hình đã tải xuống.

• Hãy xem tệp cấu hình mẫu mà tôi có bên dưới:

  

  mà bạn phải đối sánh với điều này trong khi thêm Đường hầm của mình trong GCP -> Kết nối kết hợp -> VPN thiết lập kết nối. Xem hình ảnh bên dưới mà tôi đã tạo bộ định tuyến đám mây và phiên BGP trong khi tạo đường hầm mẫu:

  

  Sau đó, phiên BGP với tư cách là,

  

  Lưu ý: Tệp cấu hình đã tải xuống chứa đường hầm cấu hình IPSec mà AWS cũng chứa hai (2) máy chủ VPN sẵn sàng cho kết nối của bạn. Bạn phải thiết lập cả hai để bạn có một thiết lập khả dụng cao. Sau khi thiết lập chính xác cho cả hai đường hầm, kết nối AWS VPN trong tab Đường hầm sẽ hiển thị rằng cả Địa chỉ IP bên ngoài đang lên. Xem hình ảnh bên dưới:

  

• Cuối cùng, vì chúng tôi đã tạo Cổng Internet và Cổng NAT, hãy điền chính xác các mạng con công cộng và mạng riêng với đúng Đích và Mục tiêu như đã nhận thấy trong ảnh chụp màn hình từ các bước trước. Điều này có thể được thiết lập bằng cách đi tới Dịch vụ -> Mạng &Cung cấp Nội dung -> VPC -> Bảng Định tuyến và chọn các bảng lộ trình đã tạo được đề cập từ các bước trước. Xem hình ảnh bên dưới:

  

  Như bạn đã nhận thấy, igw-01faa6d83da5df964 là Cổng Internet mà chúng tôi đã tạo và được sử dụng theo đường công cộng. Trong khi đó, bảng tuyến đường riêng có điểm đến và mục tiêu được đặt thành nat-07eb7a54e90dab61f và cả hai đều có Đích đến đặt thành 0.0.0.0/0 vì nó sẽ cho phép từ các kết nối IPv4 khác nhau. Cũng đừng quên đặt Tuyên truyền tuyến đường đúng cho Cổng ảo như được thấy trong ảnh chụp màn hình có đích là vgw-0238040a5fd061515 . Chỉ cần nhấp vào Định tuyến và đặt thành Có giống như trong ảnh chụp màn hình bên dưới:

  

  Điều này rất quan trọng để kết nối từ các kết nối GCP bên ngoài sẽ định tuyến đến các bảng định tuyến trong AWS và không cần thực hiện thêm thao tác thủ công nào nữa. Nếu không, GCP của bạn không thể thiết lập kết nối với AWS.

Bây giờ VPN của chúng tôi đã hoạt động, chúng tôi sẽ tiếp tục thiết lập các nút riêng tư của mình bao gồm cả máy chủ pháo đài.

Thiết lập các nút Công cụ tính toán

Việc thiết lập các nút Compute Engine / EC2 sẽ nhanh chóng và dễ dàng vì chúng tôi đã thiết lập xong tất cả. Tôi sẽ không đi sâu vào chi tiết đó nhưng hãy xem ảnh chụp màn hình bên dưới vì nó giải thích cách thiết lập.

Nút AWS EC2 :

Nút tính toán GCP :

Về cơ bản, trên thiết lập này. Máy chủ lưu trữ điều khiển cụm sẽ là pháo đài hoặc máy chủ lưu trữ jump và ClusterControl sẽ được cài đặt. Rõ ràng, tất cả các nút ở đây đều không thể truy cập internet. Chúng không được gán IPv4 bên ngoài và các nút đang giao tiếp thông qua một kênh rất an toàn bằng VPN.

Cuối cùng, tất cả các nút này từ AWS đến GCP đều được thiết lập với một người dùng hệ thống thống nhất có quyền truy cập sudo, cần có trong phần tiếp theo của chúng tôi. Xem cách ClusterControl có thể giúp cuộc sống của bạn dễ dàng hơn khi ở trong nhiều đám mây và nhiều vùng.

ClusterControl To The Rescue !!!

Xử lý nhiều nút và trên các nền tảng đám mây công cộng khác nhau, cộng với một "Khu vực" khác có thể là một nhiệm vụ "thực sự đau đớn và khó khăn". Làm thế nào để bạn giám sát điều đó một cách hiệu quả? ClusterControl không chỉ hoạt động như một con dao Thụy Sĩ của bạn mà còn như một DBA ảo của bạn. Bây giờ, hãy xem cách ClusterControl có thể giúp cuộc sống của bạn dễ dàng hơn.

Tạo một cụm sao chép nhiều lần bằng ClusterControl

Bây giờ chúng ta hãy thử tạo một cụm sao chép chủ-nô MariaDB theo cấu trúc liên kết "Nhiều bản sao".

Trình hướng dẫn triển khai ClusterControl

Đánh Triển khai nút sẽ cài đặt các gói và thiết lập các nút cho phù hợp. Do đó, một cái nhìn logic về cách cấu trúc liên kết sẽ trông như thế nào:

ClusterControl - Chế độ xem cấu trúc liên kết

Các nút của dải IP 172.21.0.0/16 đang sao chép từ chính của nó đang chạy trên GCP.

Bây giờ, làm thế nào về việc chúng tôi thử tải một số ghi trên trang chủ? Bất kỳ vấn đề nào với kết nối hoặc độ trễ có thể tạo ra độ trễ nô lệ, bạn sẽ có thể phát hiện điều này với ClusterControl. Xem ảnh chụp màn hình bên dưới:

và như bạn thấy ở góc trên cùng bên phải của ảnh chụp màn hình, nó chuyển sang màu đỏ vì nó cho biết sự cố đã được phát hiện. Do đó, một báo động đã được gửi trong khi vấn đề này đã được phát hiện. Xem bên dưới:

Chúng ta cần phải đào sâu vào điều này. Để theo dõi chi tiết, chúng tôi đã kích hoạt các tác nhân trên các cá thể cơ sở dữ liệu. Hãy xem Trang tổng quan.

Nó mang lại trải nghiệm siêu mượt về mặt giám sát các nút của bạn.

Nó cho chúng ta biết rằng hiệu suất sử dụng cao hoặc máy chủ lưu trữ không phản hồi. Mặc dù đây chỉ là một ping phản ứng thất bại, bạn có thể bỏ qua cảnh báo để ngăn bạn bắn phá nó. Do đó, bạn có thể ‘bỏ qua’ nó nếu cần bằng cách đi tới Cluster -> Alarms in the Clustercontrol. Xem bên dưới:

Quản lý lỗi và thực hiện chuyển đổi dự phòng

Giả sử rằng nút chính us-East1 không thành công hoặc yêu cầu đại tu do nâng cấp hệ thống hoặc phần cứng. Giả sử đây là cấu trúc liên kết ngay bây giờ (xem hình ảnh bên dưới):

Hãy thử tắt máy chủ 10.142.0.7 là máy chủ trong khu vực miền đông chúng tôi1. Xem ảnh chụp màn hình bên dưới cách ClusterControl phản ứng với điều này:

ClusterControl sẽ gửi cảnh báo khi nó phát hiện ra sự bất thường trong cụm. Sau đó, nó cố gắng thực hiện chuyển đổi dự phòng sang chủ mới bằng cách chọn ứng viên phù hợp (xem hình ảnh bên dưới):

Sau đó, nó đặt bản cái bị lỗi sang một bên đã được lấy ra khỏi cụm (xem hình ảnh bên dưới):

Đây chỉ là một cái nhìn sơ lược về những gì ClusterControl có thể làm, còn có các tính năng tuyệt vời khác như sao lưu, giám sát truy vấn, triển khai / quản lý bộ cân bằng tải và nhiều tính năng khác!

Kết luận

Quản lý thiết lập Bản sao MySQL của bạn trong một đám mây có thể phức tạp. Cần phải cẩn thận hơn nhiều để bảo mật thiết lập của chúng tôi, vì vậy hy vọng blog này cung cấp ý tưởng về cách xác định mạng con và bảo vệ các nút cơ sở dữ liệu. Sau khi bảo mật, có một số thứ cần quản lý và đây là lúc ClusterControl có thể rất hữu ích.

Hãy thử nó ngay bây giờ và hãy cho chúng tôi biết nó diễn ra như thế nào. Bạn có thể liên hệ với chúng tôi tại đây bất cứ lúc nào.