Khi mạng gia đình và số lượng dịch vụ tự host (self-host) của tôi ngày càng phát triển, sự phụ thuộc vào các dịch vụ đó cũng tăng lên. Đây là sự đánh đổi giữa quyền riêng tư khi dữ liệu nằm chắc chắn trên các thiết bị thuộc sở hữu của tôi thay vì trên các máy chủ đám mây của các công ty khác, và nó đi kèm với nhiều trách nhiệm bổ sung. Tôi sẵn lòng chấp nhận điều đó, nhưng điều này đồng nghĩa với việc tôi cần tìm cách đảm bảo tính sẵn sàng cao cho các dịch vụ này, bởi vì tôi không phải là người duy nhất trong gia đình sử dụng, và mọi sự cố gián đoạn giờ đây đều là vấn đề của tôi.
Điều này đã dẫn đến việc tôi phải xây dựng một cụm Proxmox với tính sẵn sàng cao, giúp giảm thiểu khả năng các máy ảo (VM) ngừng hoạt động. Tuy nhiên, vẫn còn một điểm lỗi đơn lẻ về kết nối mạng. Và rồi tôi tìm thấy Keepalived, một công cụ sử dụng giao thức dự phòng bộ định tuyến ảo (VRRP) để chia sẻ nhiều máy chủ hoặc dịch vụ trên một địa chỉ IP ảo (Virtual IP – VIP) duy nhất, đồng thời cung cấp phương pháp chống lỗi (failover) nếu một trong số chúng gặp sự cố. Đây là một công cụ tuyệt vời để xây dựng một mạng lưới kiên cường hơn và hoạt động gần như liền mạch. Thực tế, tôi có thể sử dụng HAProxy cho một tính năng chống lỗi tương tự và nhận được khả năng cân bằng tải, nhưng điều gì sẽ giữ cho HAProxy không bị sập? À, đúng rồi, một phiên bản Keepalived khác. Tôi sẽ tuân thủ các giải pháp đơn giản mà tôi biết, ít nhất là ở giai đoạn này.
Nhiều thẻ nhớ SD cho Raspberry Pi, đại diện cho các thiết bị tự host dịch vụ
5. Dành cho các máy chủ DNS của tôi
Technitium mạnh mẽ, nhưng cần Keepalived cho đến khi có tính năng clustering
Tự host một máy chủ DNS là một quá trình đáng giá, mang lại sự riêng tư cần thiết cho các thiết bị, mạng và thông tin cá nhân của bạn. Trong bối cảnh mọi hoạt động trên internet đều có nguy cơ bị theo dõi và kiếm tiền theo một cách nào đó, chúng ta nên thực hiện các biện pháp phòng ngừa. Đồng nghiệp của tôi, Adam, cũng có hai máy chủ Pi-hole vì lý do này, để nếu một cái ngừng hoạt động, cái kia sẽ tiếp quản và mạng của anh ấy vẫn được bảo vệ.
Tôi cũng làm điều tương tự, nhưng với Technitium – một máy chủ DNS đầy đủ tính năng mà bạn có thể tự host. Lộ trình phát triển của nó có tính năng clustering (phân cụm) sắp ra mắt, vì vậy tại một thời điểm nào đó, tôi sẽ có thể kết nối nhiều phiên bản với nhau bằng các cài đặt tích hợp. Nhưng ngày đó vẫn còn ở phía trước. Cho đến khi điều đó xảy ra, tôi đã sử dụng Keepalived trên NAS và trên một máy mini PC chạy Proxmox, cho phép tôi sử dụng một IP ảo duy nhất để truy cập cả hai phiên bản Technitium. Điều khác biệt duy nhất để nó hoạt động là thêm dòng lệnh sau vào các máy chủ, sau đó liên kết Technitium với cả IP máy chủ và IP ảo trong Keepalived, và thêm IP ảo vào cài đặt DNS Server Local End Points trong Technitium.
net.ipv4.ip_nonlocal_bind=1
Giao diện bảng điều khiển Pi-hole hiển thị trên trình duyệt của máy tính xách tay Windows, minh họa cho việc tự host DNS server
4. Vì hệ thống nhà thông minh của tôi là tối quan trọng
Home Assistant không nên có điểm lỗi đơn lẻ
Tôi sử dụng Home Assistant để tự động hóa ngôi nhà thông minh của mình và liên kết nhiều hệ sinh thái khác nhau mà tôi đã thu thập qua nhiều năm thành một khối thống nhất. Điều này hoạt động cực kỳ hiệu quả khi máy ảo Home Assistant (VM HA) trên NAS của tôi có thể truy cập được bởi phần còn lại của mạng, nhưng đôi khi kết nối đến thiết bị đó bị gián đoạn. Bạn sẽ không chấp nhận việc các máy chủ Google Home hoặc HomeKit ngừng hoạt động trong một khoảng thời gian đáng kể, và tôi chắc chắn cũng không chấp nhận việc Home Assistant của tôi làm điều tương tự.
Nhưng với Keepalived, tôi không phải lo lắng về điều đó. Tôi có thể giữ VM HA đó làm máy chủ chính để định tuyến các yêu cầu, và có một container Docker với Home Assistant chạy trên thiết bị có Docker compose stack của tôi, đồng thời có một thành phần Keepalived để kiểm tra xem VM chính có đang chạy hay không. Với gói đăng ký Home Assistant Cloud, tôi có các bản sao lưu để dễ dàng duy trì sự đồng bộ giữa hai phiên bản HA. Một vài tính năng mà container Docker không thể chạy không phải là dịch vụ thiết yếu đối với tôi, vì vậy việc chúng không khả dụng trong thời gian ngắn cho đến khi tôi khởi động lại NAS hoặc khắc phục sự cố kết nối cũng không thành vấn đề.
Giao diện Home Assistant với các tùy chọn Jukebox Helpers, biểu thị hệ thống nhà thông minh tự động hóa
3. Để Reverse Proxy của tôi không bao giờ ngừng hoạt động
Khả năng truy cập là tất cả trong homelab
Reverse proxy của tôi là cổng dẫn đến các dịch vụ tự host, khiến nó trở thành một phần thiết yếu trong kiến trúc mạng của tôi và là một điểm lỗi đơn lẻ (SPOF) nếu có bất kỳ sự cố nào xảy ra. Hầu hết các dịch vụ của tôi đều chạy trên các máy chủ dựa trên Ubuntu hoặc Debian, bao gồm cả Proxmox, vì đây là những hệ điều hành mà tôi đã quen thuộc và tôi muốn tập trung học hỏi kiến trúc mạng mà tôi ít biết hơn. Dù tôi sử dụng Nginx hay HAProxy làm reverse proxy, cả hai đều dễ dàng liên kết với Keepalived. Tất cả những gì tôi cần là ba địa chỉ IP và nhớ thay đổi priority (độ ưu tiên) của hai phiên bản VRRP để một cái cao hơn cái kia.
$ sudo iptables -I INPUT -p 112 -d 224.0.0.18 -j ACCEPT
$ sudo iptables -I INPUT -p 51 -d 224.0.0.18 -j ACCEPTLần đầu tiên tôi thiết lập, mọi thứ đều trông có vẻ đúng, vì vậy tôi không thể tìm ra nguyên nhân gây ra sự cố. Sau đó, tôi tìm thấy một hướng dẫn khác đề cập đến việc thêm các quy tắc tường lửa cho vrrp và ah (xác thực) để cho phép chúng đi qua, điều này khá đơn giản trong Ubuntu.
Hệ thống homelab với các thiết bị Proxmox, thể hiện kiến trúc mạng phức tạp
2. Để VPN của tôi luôn sẵn sàng
Dịch vụ gián đoạn khi ở nhà đã đủ tệ
Truy cập từ xa vào mạng và homelab của tôi là điều cần thiết đối với kiến trúc của tôi. Nhưng chuỗi kết nối được tạo ra cẩn thận đó sẽ trở nên vô dụng nếu máy chủ chạy OpenVPN gặp sự cố. Nếu tôi sử dụng OpenVPN vì bất kỳ lý do gì, tôi sẽ chạy nó trên hai máy chủ, với chúng được liên kết với IP ảo trong Keepalived và IP riêng của chúng. Điều này giúp máy chủ phụ hoạt động như máy chủ chính khi kết nối bị mất vì bất kỳ lý do gì.
Điều đó có nghĩa là máy chủ VPN của tôi luôn sẵn sàng. Và nếu điều tồi tệ nhất xảy ra và hai máy chủ trong mạng gia đình của tôi ngừng hoạt động, tôi sẽ có những vấn đề lớn hơn nhiều so với việc không thể đăng nhập từ xa. Tôi có thể làm điều tương tự với Pangolin, nhưng tôi vẫn sẽ gặp vấn đề tương tự với các địa chỉ IP mà Pangolin được ánh xạ đến bị ngừng hoạt động. Ít nhất, trừ khi tôi cũng chạy Keepalived trên tất cả các dịch vụ đó. Tôi nghĩ cuối cùng tôi sẽ có các máy chủ ứng dụng được đồng bộ hóa đằng sau hai phiên bản HAProxy và Keepalived để mọi thứ có cơ hội hoạt động cao nhất, nhưng điều đó vẫn còn ở tương lai khi tôi lên kế hoạch mua sắm tiếp theo.
Một người đang kiểm tra trang web trên laptop, tượng trưng cho việc truy cập từ xa và an toàn qua VPN
Một homelab nhỏ gọn được lắp trong tủ rack, minh họa cho hệ thống máy chủ cá nhân
1. Để dễ dàng quản lý cụm Proxmox của tôi
Tính năng HA failover của Proxmox quá chậm, IP ảo là chìa khóa
Thiết lập một cụm Proxmox với tính năng sẵn sàng cao (HA) là một cách tuyệt vời để đảm bảo các container và máy ảo của bạn luôn sẵn sàng cho người dùng. Nhưng điều gì sẽ xảy ra khi bạn cần thực hiện các tác vụ quản trị trên các node Proxmox? Nếu một node bị hỏng, bạn cần biết đó là node nào để có thể sử dụng một trong các node khác. Theo ý kiến của tôi, các tác vụ quản trị nên được thiết lập sao cho ít ma sát nhất có thể.
Việc cấu hình Keepalived để truy cập cụm với một địa chỉ IP ảo duy nhất giúp tiết kiệm thời gian khi tôi cần thay đổi điều gì đó. Nó sẽ luôn đăng nhập vào node đang hoạt động, điều này rất tiện lợi và dễ dàng. Có thể mỗi lần đăng nhập chỉ mất vài giây, nhưng thời gian đó sẽ cộng dồn theo thời gian, và tôi sẽ sử dụng cụm này trong một thời gian dài.
Cụm máy chủ Proxmox gồm hai node, thể hiện khả năng quản lý và tính sẵn sàng cao
Tôi sẽ dùng Keepalived cho mọi thứ (nếu có thể)
Gần đây tôi cũng đã chuyển tường lửa của mình sang OPNsense, và Keepalived không hoàn toàn hoạt động trong tình huống đó. Điều này là do OPNsense đã tích hợp sẵn CARP, cho phép bạn nhanh chóng tạo một cụm với khả năng chống lỗi mà không cần thêm bất kỳ công cụ nào khác. Nếu không có CARP, tôi sẽ phải tìm cách thiết lập tính năng chống lỗi, cộng với việc đồng bộ hóa cài đặt giữa hai tường lửa. Lý tưởng nhất, tôi muốn mọi dịch vụ hoặc máy chủ tôi chạy đều có tính năng clustering gốc để không cần cài đặt bổ sung, nhưng Keepalived sẽ hoàn thành tốt công việc cho đến lúc đó.
Keepalived thực sự là một giải pháp hữu hiệu để giảm thiểu các điểm lỗi đơn lẻ và tăng cường đáng kể độ tin cậy của các dịch vụ tự host trong môi trường mạng gia đình hoặc homelab. Việc đầu tư thời gian tìm hiểu và triển khai công cụ này chắc chắn sẽ mang lại sự yên tâm và trải nghiệm liền mạch hơn cho người dùng. Bạn đã từng sử dụng Keepalived hay giải pháp tương tự chưa? Hãy chia sẻ kinh nghiệm của bạn trong phần bình luận bên dưới hoặc khám phá thêm các bài viết khác về tối ưu mạng gia đình tại camnangcongnghe.net!