कैसे 5 VPS से 1 डेडिकेटेड सर्वर पर Proxmox के साथ गया और होस्टर्स को खिलाना बंद कर दिया

TL;DR: तीन प्रदाताओं से पाँच VPS का खंडित इंफ्रा → एक डेडिकेटेड सर्वर Ryzen 7 9700X / 64GB ECC / 2× NVMe ZFS-mirror, Proxmox VE के ऊपर। अंदर - भूमिकाओं के अनुसार VM/LXC, पोर्ट फॉरवर्डिंग के बजाय NetBird-मेश, ब्लॉकेज को बायपास करने और TLS-टर्मिनेशन के लिए एक अलग VPS पर आउटगोइंग नोड, बैकअप के लिए PBS। पैसे का मुनाफा, नियंत्रण का मुनाफा, नसों का मुनाफा। इस लेख में - क्यों, कैसे, और रास्ते में कहाँ ठोकर खाई, ताकि आप न खाएं।

Open

मैंने यह सब शुरू ही क्यों किया

पिछले साल के अंत तक, मैंने पाया कि मैं तीन होस्टरों से पाँच अलग-अलग VPS के लिए भुगतान कर रहा था। एक - Discourse फोरम के लिए, दूसरा - PHP पर MySQL के साथ लेगेसी फोरम के लिए, तीसरा - बिलिंग और टेलीग्राम बॉट्स के लिए, चौथा - VPN/प्रॉक्सी, पाँचवाँ - स्टैटिक और विभिन्न छोटे टूल्स के लिए। और n8n भी कहीं घूम रहा था, और Vaultwarden, और कुछ Uptime Kuma जो एक-दूसरे की निगरानी कर रहे थे (और कैसे नहीं)।

क्या गलत था:

• पैसे। कुल मिलाकर, यह उतना ही था जितना कि इन सभी को मिलाकर एक सभ्य डेडिकेटेड सर्वर की कीमत होती (लेकिन वहां शेयर्ड था, यहां डेडिकेटेड)।
• कोई अलगाव नहीं। यदि किसी एक क्लाइंट का बॉट मेमोरी लीक करना शुरू कर देता है - तो मेरा फोरम धीमा होने लगता है। उसी सर्वर पर। बढ़िया।
• बैकअप - बकवास। प्रत्येक VPS पर अपना rsync-क्रॉन S3 में, हर जगह अलग-अलग प्रतिधारण, कोई वृद्धिशील नहीं, पुनर्स्थापित करना - एक पूरा रोमांच।
• नेटवर्क एक सलाद की तरह। SSH विभिन्न पोर्ट के माध्यम से, Cloudflare Tunnels के माध्यम से फॉरवर्ड किया गया, दो VPS के बीच मैन्युअल रूप से उठाया गया WireGuard, तीन जगहों पर कॉन्फ़िगरेशन के साथ। हर बार जब मैंने एक नई मशीन जोड़ी - एक दिन एकीकरण में चला गया।
• अपडेट-एपोकैलिप्स। पांच अलग-अलग Ubuntu/Debian पर अलग-अलग संस्करणों और पैकेजों के साथ अपग्रेड को मैन्युअल रूप से किया जाना चाहिए और कभी भी एक साथ नहीं। हर छह महीने में, मैंने "सब कुछ अपडेट करें, कुछ भी तोड़ें नहीं" का नायकों की तरह सामना किया।
• CPU और RAM निष्क्रिय पड़े हैं। प्रत्येक VPS को "पीक" के लिए बुक किया गया था, और औसतन 15-20% उपयोग किया जाता है। पैसा हवा में उड़ रहा था।

कुल मिलाकर - यह एक क्लासिक मामला था जब इंफ्रास्ट्रक्चर "ओह, एक और सेवा की आवश्यकता है - एक VPS खरीदूंगा" के सिद्धांत पर विकसित हुआ। यह सब समेकित करने का समय था।

मैंने क्या चुना और क्यों

हार्डवेयर

मैंने एक डेडिकेटेड सर्वर लिया:

• CPU: AMD Ryzen 7 9700X (8 कोर / 16 थ्रेड, Zen 5)
• RAM: 64 GB DDR5 ECC 5200 MHz
• डिस्क: 2× NVMe 512 GB एंटरप्राइज़ → ZFS मिरर
• नेटवर्क: 1 Gbps अनमीटर्ड
• कीमत: उसी OVH पर दो औसत VPS के बराबर

हाइपरवाइजर

Proxmox VE 9.x। मैंने विकल्पों पर विचार किया, लेकिन संक्षेप में:

• प्लेन Docker - कोई अलगाव नहीं, कोई उचित स्नैपशॉट नहीं, केवल कंपोज के माध्यम से बैकअप, डिस्क - एक एकल कूड़ेदान।
• VMware ESXi - अब मुफ्त नहीं है, Broadcom लाइसेंस बहुत अच्छा है, धन्यवाद।
• XCP-ng - ठीक है, लेकिन व्यक्तिगत रूप से मैं Proxmox को अच्छी तरह जानता हूं और समुदाय अधिक जीवंत है।
• Kubernetes - नहीं, मैं अकेला व्यक्ति हूं, मुझे स्टोर तक जाने के लिए विमान बनाने की आवश्यकता नहीं है।

Proxmox मुझे वह सब कुछ देता है जिसकी मुझे आवश्यकता है: KVM-वर्चुअल मशीनें उन सभी के लिए जिन्हें अलगाव की आवश्यकता है (Docker, विशिष्ट कर्नेल, विभिन्न वितरण); LXC कंटेनर जहां संसाधनों को बचाया जा सकता है (DB, निगरानी, ​​छोटे सेवाएं); अंतर्निहित PBS बैकअप के लिए; ZFS आउट-ऑफ-द-बॉक्स; स्नैपशॉट; लाइव माइग्रेशन (यदि कभी दूसरा समर्पित सर्वर आता है); वेब इंटरफ़ेस, जहां आप माउस से क्लिक कर सकते हैं जब आप टर्मिनल में लिखना नहीं चाहते हैं।

आर्किटेक्चर: सामान्य योजना

पहले मैं दिखाऊंगा कि क्या मिला, फिर बताऊंगा कि मैं यहां कैसे पहुंचा। Open

तर्क इस प्रकार है:

1. समर्पित सर्वर पर Proxmox रहता है। यह vmbr0 पर सार्वजनिक IP Y.Y.Y.Y रखता है।
2. अंदर एक दूसरा ब्रिज vmbr1 बनाया गया है जिसमें एक निजी नेटवर्क 10.10.10.0/24 है। यह "आंतरिक LAN" का एनालॉग है - सभी VM और LXC वहां जुड़े हुए हैं, बाहर NAT के माध्यम से होस्ट से, उनके पास कोई बाहरी सार्वजनिक पोर्ट नहीं है।
3. होस्ट पर ही केवल तीन चीजें चलती हैं: Caddy (आंतरिक रिवर्स प्रॉक्सी), nftables (फ़ायरवॉल) और NetBird (VPN एजेंट)। होस्ट पर कोई Docker नहीं, होस्ट पर कोई एप्लिकेशन लॉजिक नहीं। होस्ट एक पवित्र गाय है, इसका काम एक हाइपरवाइजर होना और क्रैश न होना है।
4. वर्चुअल मशीनें भूमिकाओं के अनुसार विभाजित हैं: एक फोरम के लिए, एक बैकग्राउंड सेवाओं और बॉट्स के लिए, एक Dokploy के साथ कस्टम अनुप्रयोगों के लिए, आदि। उनके बीच 10.10.10.x पर सीधी दृश्यता है, बाहर - केवल होस्ट Caddy के माध्यम से।
5. LXC कंटेनर - "हल्की" सभी चीजों के लिए: विभिन्न संस्करणों के कई Postgres इंस्टेंस, Proxmox Backup Server, निगरानी डैशबोर्ड। वे भी vmbr1 में हैं।
6. एक अलग आउटगोइंग नोड ("Peer Caddy") - एक अलग प्रदाता से एक छोटा VPS है, जो मेरे दर्शकों के लिए उपयुक्त नेटवर्क में है। इस पर Caddy चलता है, जो TLS (Let's Encrypt) को समाप्त करता है और NetBird-मेश के माध्यम से समर्पित सर्वर के अंदर HTTP को प्रॉक्सी करता है। सभी सार्वजनिक डोमेन के लिए DNS इस VPS को इंगित करता है, समर्पित सर्वर को नहीं।
7. NetBird मेश समर्पित सर्वर, आउटगोइंग नोड और मेरे लैपटॉप (और कुछ पुराने सर्वर जहां से सब कुछ स्थानांतरित नहीं हुआ है) को जोड़ता है। यह SSO प्रमाणीकरण के ऊपर WireGuard है, बाहर खुले पोर्ट के बिना।

आउटगोइंग नोड के माध्यम से इस तरह के अलगाव की आवश्यकता क्यों है - यह एक अलग चर्चा है, जिस पर मैं वापस आऊंगा।

Proxmox स्थापना: मैंने इसे कैसे उठाया

मैंने समर्पित सर्वर का आदेश दिया, पहले बूट में मैंने rescue-mode/KVM के माध्यम से Proxmox स्थापित किया (OVH में दोनों उपलब्ध हैं - KVM मेरे लिए अधिक सुविधाजनक है, यह पूरी प्रक्रिया दिखाता है)। स्थापना के दौरान:

• ZFS RAID1 दोनों NVMe पर (ashift=12, compression=lz4 तुरंत चालू किया गया)
• डिफ़ॉल्ट विभाजन, Proxmox स्वयं rpool/ROOT, rpool/data, swap बनाता है

इसके बाद - स्थापना के बाद बुनियादी सफाई। यह आवश्यक है, इसके बिना Proxmox सदस्यता त्रुटियों से भर जाता है और अनुकूलित रूप से काम नहीं करता है।

1# 1. एंटरप्राइज रेपो हटाएं (सदस्यता नहीं है)
2sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
3echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
4  > /etc/apt/sources.list.d/pve-no-subscription.list
5apt update && apt full-upgrade -y
6
7# 2. "No valid subscription" पॉप-अप हटाएं
8sed -Ezi.bak "s/(Ext\.Msg\.show\(\{[^}]+?title: gettext\('No valid sub)/void\(\{ \/\/\1/g" \
9  /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
10systemctl restart pveproxy
11
12# 3. होस्टनाम / समय क्षेत्र
13hostnamectl set-hostname dedik-waw
14timedatectl set-timezone Europe/Warsaw

SSH हार्डनिंग

तुरंत। "बाद में" नहीं। बाद में - कभी नहीं आता।

1cat > /etc/ssh/sshd_config.d/hardening.conf << 'EOF'
2Port 22222
3PermitRootLogin prohibit-password
4PasswordAuthentication no
5MaxAuthTries 3
6ClientAliveInterval 300
7ClientAliveCountMax 2
8EOF
9
10mkdir -p ~/.ssh
11echo "ssh-ed25519 AAAA... your-key" >> ~/.ssh/authorized_keys
12chmod 600 ~/.ssh/authorized_keys
13systemctl restart sshd

फ़ायरवॉल में पोर्ट 22 बंद कर दिया, केवल गैर-मानक पोर्ट छोड़ दिया। यह सुरक्षा के माध्यम से अस्पष्टता नहीं है, यह लॉग में पृष्ठभूमि शोर को कम करना है - पहले घंटे में पोर्ट 22 पर 50 हजार ब्रूट-फोर्स प्रयास आते हैं, लॉग में कुछ भी दिखाई नहीं देता। पोर्ट 22222 पर - खामोशी है और विसंगतियों की वास्तविक निगरानी संभव है।

ZFS - NVMe और 64GB RAM के लिए कॉन्फ़िगरेशन

ZFS डिफ़ॉल्ट रूप से ARC के लिए RAM का आधा हिस्सा लेना चाहता है। यह एक फ़ाइल सर्वर के लिए सामान्य है और एक हाइपरवाइजर के लिए बिल्कुल विपरीत है, जहां वर्चुअल मशीनों के लिए मेमोरी की आवश्यकता होती है। हम ARC को उचित 16 GB तक दबाते हैं:

1cat > /etc/modprobe.d/zfs.conf << 'EOF'
2options zfs zfs_arc_max=17179869184
3options zfs zfs_arc_min=4294967296
4EOF
5update-initramfs -u

मेरी मेमोरी का वितरण:

• ~16 GB — ZFS ARC
• ~44 GB — VM/LXC
• ~4 GB — सिस्टम, बफ़र्स, ओवरहेड

पूल के उपयोगी कॉन्फ़िगरेशन:

1zfs set compression=lz4 rpool
2zfs set atime=off rpool
3zfs set xattr=sa rpool
4zfs set dnodesize=auto rpool
5zfs set relatime=on rpool
6
7zfs set recordsize=64K rpool/data    # VM डिस्क के लिए
8zfs set sync=standard rpool/data
9
10zpool set autotrim=on rpool          # NVMe के लिए महत्वपूर्ण

compression=lz4 CPU पर लगभग मुफ्त में 20-30% स्थान बचाता है। VM डिस्क उपकरणों के लिए recordsize=64K - राइट एम्प्लीफिकेशन और प्रदर्शन के बीच सबसे अच्छा समझौता है।

आंतरिक नेटवर्क और फ़ायरवॉल

NAT आउटगोइंग के साथ एक निजी नेटवर्क के लिए एक दूसरा ब्रिज बनाया:

1auto vmbr1
2iface vmbr1 inet static
3    address 10.10.10.1/24
4    bridge-ports none
5    bridge-stp off
6    bridge-fd 0
7    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
8    post-up   iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE
9    post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

अब ब्रिज vmbr1 में कोई भी VM/LXC एक स्थानीय पता 10.10.10.x प्राप्त करता है और होस्ट के माध्यम से इंटरनेट पर जाता है, लेकिन बाहर से दिखाई नहीं देता।

nftables के साथ policy drop। केवल वही खुला है जो खुला होना चाहिए, बाकी सब मूक रूप से गिरा दिया जाता है। न्यूनतम सेट:

1table inet filter {
2    chain input {
3        type filter hook input priority 0; policy drop;
4
5        iif lo accept
6        ct state established,related accept
7        ip protocol icmp accept
8        ip6 nexthdr icmpv6 accept
9
10        tcp dport 22222 accept           # SSH
11        tcp dport 8006 accept            # Proxmox UI (केवल NetBird से, नीचे देखें)
12        tcp dport { 80, 443, 8080 } accept   # Caddy
13        udp dport 29899 accept           # NetBird
14
15        iif vmbr1 accept                 # आंतरिक नेटवर्क - सब कुछ अनुमत है
16        iif wt0 accept                   # NetBird इंटरफ़ेस - भी विश्वसनीय
17    }
18
19    chain forward {
20        type filter hook forward priority 0; policy drop;
21        iif vmbr1 oif vmbr0 accept
22        ct state established,related accept
23    }
24}

Proxmox UI (पोर्ट 8006) तक पहुंच को CF/फ़ायरवॉल से भौतिक रूप से बंद कर दिया गया है और केवल NetBird के माध्यम से एक्सेस किया जाता है। सार्वजनिक IP पर इंटरफ़ेस बिल्कुल भी प्रतिक्रिया नहीं देता है। वही PBS UI, डैशबोर्ड और सभी एडमिनिस्ट्रेटिव - केवल मेश के माध्यम से। बाहर केवल सेवाओं के वास्तव में सार्वजनिक पोर्ट खुले हैं।

NetBird मेश: क्लासिक WireGuard क्यों नहीं

मैंने सामान्य WireGuard का बहुत उपयोग किया, और यह ठीक था, जब तक सर्वर तीन से अधिक नहीं हो गए। इसके बाद - कॉन्फ़िगरेशन का प्रबंधन दर्दनाक हो गया: प्रत्येक पीयर को जोड़ना "सभी नोड्स पर कॉन्फ़िगरेशन अपडेट करें, allowed_ips को न भूलें, डेमन को पुनरारंभ करें, सुनिश्चित करें कि आपने दूसरे पीयर के मार्ग को नहीं तोड़ा" में बदल जाता है।

NetBird WireGuard के ऊपर एक प्रबंधन प्लेन है। तकनीकी रूप से, आपके पास अभी भी उसी wg के नीचे है, लेकिन:

• नोड्स सिग्नलिंग सर्वर के माध्यम से एक-दूसरे को ढूंढते हैं, NAT-traversal स्वचालित है।
• SSO के माध्यम से प्रमाणीकरण (मेरे पास - Authentik के माध्यम से), कुंजियों को साझा किए बिना।
• एक्सेस वेब इंटरफ़ेस के माध्यम से नीतियों के माध्यम से प्रबंधित किया जाता है, आप मशीनों और उनके बीच के नियमों के समूह बना सकते हैं।
• अंतर्निहित SSH प्रॉक्सी: आप ssh user@machine.netbird.cloud के माध्यम से जा सकते हैं और SSO प्रमाणीकरण प्राप्त कर सकते हैं (Authentik में अनुमोदन के साथ)। नोड पर बाहर SSH पोर्ट खोलने की भी आवश्यकता नहीं है।

मैंने NetBird एजेंट को उठाया:

• Proxmox होस्ट पर
• प्रत्येक VM पर जिसे एडमिन या अन्य VM द्वारा देखा जाना चाहिए।
• आउटगोइंग नोड पर।
• मेरे लैपटॉप पर।

परिणामस्वरूप, मैं लैपटॉप से किसी भी मशीन पर एक कमांड से जाता हूं, पोर्ट फॉरवर्डिंग के बिना, फ़ायरवॉल छिद्रों के बिना, अतिरिक्त बैस्टियन होस्ट के बिना। और किसी भी निजी VM पर कोई खुला SSH नहीं है - वे सभी केवल vmbr1 प्लस मेश wt0 में हैं।

वर्चुअल मशीन बनाम कंटेनर: मैंने इसे अपने लिए कैसे हल किया

एक सरल नियम जो लगभग हमेशा काम करता है:

परिणामस्वरूप, मेरे पास लगभग ऐसा है:

वर्चुअल मशीनें (KVM):

• forum — मानक लॉन्चर कंटेनर में Discourse। अंदर Docker।
• services — बहुत सारी छोटी चीजें: वेबहुक बॉट, AI बॉट, बिलिंग पैनल, Vaultwarden, Uptime Kuma। सभी Docker कंपोज़ में, प्रत्येक सेवा के लिए एक फ़ोल्डर।
• legacy — पुराना PHP फोरम (IPS) नेटिव PHP-FPM और VM पर Caddy के साथ। इसे Docker में पैक नहीं करना चाहता था - बहुत अधिक लेगेसी, जैसा था वैसा ही छोड़ना आसान था।
• dokploy — कस्टम अनुप्रयोगों (Next.js, Postgres, Redis) के लिए Docker Swarm + Dokploy, Git के माध्यम से डिप्लॉयमेंट।

LXC:

• pbs — Proxmox Backup Server (नीचे देखें)।
• pg16, pg17, pg18 — तीन अलग-अलग प्रमुख Postgres। संबद्ध: विभिन्न अनुप्रयोगों को विभिन्न प्रमुख संस्करणों की आवश्यकता होती है, और मैं हर एक को ऊपर-नीचे ले जाने की परवाह नहीं करता।
• dashboards — Homarr (स्टार्ट पेज), Uptime Kuma और Beszel हब के साथ एक कंटेनर। तीनों एक कंपोज़ में, क्योंकि वे तार्किक रूप से एक ही चीज़ के बारे में हैं - निगरानी।

प्रत्येक VM को 10.10.10.x (रेंज के अनुसार, खोजना आसान है), 2-8 vCPU कोर और लोड के आधार पर 2-8 GB RAM मिलता है। कोर को सुरक्षित रूप से ओवरप्रोविज़न किया जा सकता है - मेरे पास VM पर कुल अधिक कोर आवंटित हैं, जितने भौतिक हैं, और यह बहुत अच्छा काम करता है, जब तक कि कोई एक साथ CPU पर लोड न हो।

रिवर्स प्रॉक्सी: डबल-लेयर्ड Caddy

Open

Proxmox के अंदर, मैंने Caddy को VM में नहीं, बल्कि होस्ट पर स्थापित किया। क्यों? क्योंकि इसे समर्पित सर्वर के सार्वजनिक पोर्ट सुनने और Host-हेडर के अनुसार आवश्यक VM पर रूट करने की आवश्यकता है, और इसके लिए पोर्ट फॉरवर्डिंग के साथ एक अलग VM बनाने के लिए - कोई लाभ के बिना एक अतिरिक्त परत। Caddy हल्का है, Go में लिखा गया है, systemd यूनिट है, एक फ़ाइल में कॉन्फ़िगरेशन है।

यह होस्ट Caddy केवल पोर्ट 8080 HTTP सुनता है और 10.10.10.x पर बैकएंड पर रूट करता है। इस पर कोई TLS नहीं है।

1:8080 {
2    @forum host forum.example.com www.forum.example.com
3    handle @forum {
4        reverse_proxy http://10.10.10.111:80 {
5            header_up X-Forwarded-Proto https
6            header_up X-Real-IP {header.X-Real-IP}
7            header_up Host {host}
8        }
9    }
10
11    @panel host panel.example.com api.panel.example.com
12    handle @panel {
13        reverse_proxy http://10.10.10.111:8081 {
14            header_up X-Forwarded-Proto https
15            header_up X-Real-IP {header.X-Real-IP}
16            header_up Host {host}
17        }
18    }
19
20    @dokploy host app1.example.com app2.example.com
21    handle @dokploy {
22        reverse_proxy http://10.10.10.114:80 {
23            header_up X-Forwarded-Proto https
24            header_up X-Real-IP {header.X-Real-IP}
25            header_up Host {host}
26        }
27    }
28}

और TLS टर्मिनेशन और प्रमाणपत्र - एक अलग आउटगोइंग नोड पर, Docker में, समान सिद्धांत पर:

1{
2    email me@example.com
3}
4
5forum.example.com {
6    reverse_proxy http://100.x.y.z:8080 {
7        header_up X-Forwarded-Proto {scheme}
8        header_up X-Forwarded-For {remote_host}
9        header_up X-Real-IP {remote_host}
10        header_up Host {host}
11    }
12}

100.x.y.z - यह समर्पित सर्वर का NetBird-पता है। अनुरोध HTTPS पर आउटगोइंग नोड पर आता है, डिक्रिप्ट होता है, HTTP के रूप में NetBird-मेश में समर्पित सर्वर पर जाता है, वहां Proxmox Caddy Host द्वारा मेल खाता है और आंतरिक VM पर रूट किया जाता है। आउटगोइंग नोड और समर्पित सर्वर के बीच HTTP डिजाइन द्वारा है - हम मेश पर भरोसा करते हैं, यहां कोई बाहरी ट्रैफिक नहीं है।

आउटगोइंग नोड की आवश्यकता क्यों है

कई कारण:

1. ब्लॉकेज को बायपास करना। OVH सबनेट का एक हिस्सा RF में ब्लॉक किया गया है। आउटगोइंग नोड एक प्रदाता के पास स्थित है जिसका IP ब्लॉक नहीं किया गया है। सार्वजनिक डोमेन के लिए DNS वहां इंगित करता है।
2. एक स्थान पर TLS टर्मिनेशन। प्रमाणपत्र केवल यह जारी करता है, Let's Encrypt के पास केवल इसके IP पर चुनौती है। यह सभी DNS-cleared check को सरल बनाता है और समर्पित सर्वर को 80/443 पर इंटरनेट से पूरी तरह से अदृश्य होने की अनुमति देता है।
3. अतिरिक्त अलगाव परत। यदि कोई DDoS शुरू करता है - तो यह आउटगोइंग नोड पर हमला करता है, न कि समर्पित सर्वर पर। मेरे पास आउटगोइंग नोड पर न्यूनतम डेटा है, इसे फिर से बनाना - 10 मिनट।
4. सार्वजनिक फ्रंट और बैकएंड का अलगाव। मैं समर्पित सर्वर पर Caddy अपडेट के साथ आराम से प्रयोग कर सकता हूं, जबकि इंटरनेट पर वास्तविक इंटरफ़ेस अलग और स्थिर है।

एक माइनस: अतिरिक्त हॉप के कारण प्रत्येक अनुरोध के लिए ~5-15 ms जोड़ता है। वेब के लिए यह अगोचर है।

साथ ही कुछ सेवाओं के लिए आउटगोइंग नोड के बिना होस्ट पर सीधे 80/443 पर Caddy है - उन डोमेन के लिए जिन्हें मुझे आउटगोइंग पॉइंट के माध्यम से प्रॉक्सी करने की आवश्यकता नहीं है (उदाहरण के लिए, स्टेटस एंडपॉइंट, निगरानी, ​​सेवा जहां DNS पहले से ही समर्पित सर्वर को इंगित करता है)। यह समानांतर में काम करता है: होस्ट पर Caddy सुनता है और :8080 (आउटगोइंग नोड से आंतरिक), और :80/:443 (इंटरनेट से प्रत्यक्ष), मार्ग अलग-अलग हैं।

माइग्रेशन: आंसू और लगभग डाउनटाइम के बिना कैसे स्थानांतरित हुआ

यह सबसे डरावना चरण था। पांच सर्वर, लगभग तीस सेवाएं, लाइव उपयोगकर्ताओं के साथ प्रोडक्शन फोरम, सक्रिय सब्सक्रिप्शन के साथ बिलिंग, डेटाबेस जिन्हें किसी भी कीमत पर खोना नहीं चाहिए।

रणनीति - एक समय में एक सेवा का माइग्रेशन, "कम से कम महत्वपूर्ण से सबसे महत्वपूर्ण" के क्रम में:

1. पहले छोटे उपकरण और स्टैटिक साइटें स्थानांतरित की गईं (यदि कुछ होता है - तो कोई भी ध्यान नहीं देगा)।
2. फिर बॉट्स और बैकग्राउंड सेवाएं (वे भी एक मिनट के डाउनटाइम को सहन कर सकते हैं)।
3. फिर डेटाबेस (पहले से जांचे गए पुनर्प्राप्ति के साथ)।
4. फिर उन अनुप्रयोगों को जो उन डीबी को देखते हैं।
5. सबसे अंत में - मुख्य फोरम एक लंबे अंतिम सिंक्रनाइज़ेशन राउंड और DNS स्विच के साथ।

माइग्रेशन चैनल

शुरू में, मैंने पुराने सर्वर पर NetBird उठाया। इसने तुरंत दो समस्याओं को हल किया: मैं आंतरिक नेटवर्क में SSH के माध्यम से सुरक्षित रूप से जा सकता हूं, और rsync NetBird पर WireGuard के माध्यम से चलता है, डेटा को खुले इंटरनेट पर उजागर किए बिना।

प्रत्येक सेवा के लिए लड़ाकू कमांड लगभग इस प्रकार थी:

1# नए समर्पित सर्वर से, पुराने सर्वर के NetBird IP के माध्यम से:
2rsync -avzP --delete \
3  -e "ssh -p 5322" \
4  root@100.76.108.210:/var/discourse/shared/standalone/ \
5  /target/discourse/shared/standalone/

डेटाबेस के लिए - डंप + पुनर्स्थापना, फ़ाइल कॉपी नहीं। MySQL/Postgres फ़ाइलों को "हॉट" कॉपी कभी न करें, यह मौत की ओर जाने वाला टिकट है।

1# पुराने पर
2docker exec -it shm-vsem-mysql mysqldump -u root -p shm-vsem | \
3  gzip > /tmp/shm-vsem.sql.gz
4
5# नए पर, NetBird के माध्यम से
6scp -P 5322 root@100.76.108.210:/tmp/shm-vsem.sql.gz /tmp/
7zcat /tmp/shm-vsem.sql.gz | docker exec -i shm-vsem-mysql mysql -u root -p shm-vsem

Discourse के लिए - देशी discourse backup / discourse restore ./launcher enter app के माध्यम से। अंदर यह स्वचालित रूप से Postgres डंप + अपलोड + कॉन्फ़िगरेशन को सही ढंग से एकत्र करता है, और इसी तरह पुनर्स्थापित करता है।

DNS स्विच

नई जगह पर सेवा उठाने और आंतरिक पते पर काम करने की जांच करने के बाद - मैंने दोनों इंस्टॉलेशन को 5-15 मिनट के लिए समानांतर में चलाया, डेटा सिंक्रनाइज़ेशन को देखने के लिए, और फिर DNS को नए सर्वर पर स्विच कर दिया। मैंने स्विच करने से एक दिन पहले रिकॉर्ड पर TTL को पहले ही 60-300 सेकंड तक कम कर दिया था।

Discourse के लिए, जो सक्रिय उपयोगकर्ताओं द्वारा लगातार पोस्ट किया जाता है, मैंने ऐसा किया:

1. नई जगह पर सब कुछ उठाया।
2. सत्यापन चलाया (लॉगिन, पोस्टिंग, S3 पर फ़ाइल अपलोड, खोज)।
3. पुराने इंस्टॉलेशन पर read_only_mode सक्षम किया (Discourse इसे आउट-ऑफ-द-बॉक्स कर सकता है)।
4. अंतिम अपलोड rsync + अंतिम डीबी डंप किया।
5. नए पर उठाया, read-only अक्षम किया।
6. DNS स्विच किया।
7. पुराने पर एक सप्ताह तक कुछ भी नहीं छुआ - "अगर ऐसा हुआ तो"।

उपयोगकर्ताओं के लिए वास्तविक डाउनटाइम - प्रति सेवा लगभग दो मिनट।

रास्ते में आश्चर्य

• pct restore पर अनुमतियाँ। unprivileged 1 के तहत LXC 100000 के ऑफसेट के साथ UID को मैप करता है। यदि आपके पुराने सर्वर पर फाइलें UID 1000 के तहत हैं - तो नए पर वे UID 101000 के तहत होंगी, और एप्लिकेशन उन्हें नहीं देखेगा। इसे या तो chown रिस्टोर के बाद, या --unprivileged 0 से हल किया जाता है यदि आप जोखिमों को समझते हैं।
• OVH VM में Docker ipv6 कभी-कभी ठीक से नहीं उठता था - Docker डेमन में ipv6 को अक्षम करने से ठीक हो गया ("ipv6": false)।
• VM पर समय। कई बार मैंने होस्ट और VM के बीच सिस्टम समय में अंतर पाया, जिससे TLS और हस्ताक्षर टूट गए। समाधान - प्रत्येक VM पर systemd-timesyncd या chrony, और Proxmox एजेंट में host.use-time।
• Discourse का दो संस्करणों के बीच माइग्रेशन। यदि पुराने सर्वर पर Discourse नए पर आपके द्वारा उठाए गए संस्करण से अधिक नया है - तो restore विफल हो जाएगा। नए इंस्टॉलेशन पर संस्करण समान या उच्च होना चाहिए।
• Dokploy के लिए इमेज रजिस्ट्री। जब मैंने Dokploy-postgres डंप के माध्यम से Dokploy मेटाडेटा का माइग्रेशन किया, तो डीबी में पुराने स्थानीय रजिस्ट्री के लिंक पुराने IP पर बने रहे। सेवाएँ 100.76.117.115:5000 में क्रैश No such image के साथ क्रैश हो गईं। समाधान - Dokploy UI में प्रत्येक एप्लिकेशन को फिर से बनाना; स्थानीय बिल्ड इमेज को पहले से ही नए सर्वर पर रखता है।

बैकअप: उसी समर्पित सर्वर के अंदर PBS + ऑफसाइट

यहां मेरे साथ एक अलग दार्शनिक बहस थी: क्या उसी हार्डवेयर पर बैकअप लेना है या नहीं। जवाब: हाँ और नहीं दोनों।

Open

स्तर 1 — पूल पर ही ZFS स्नैपशॉट। वे लगभग मुफ्त हैं (कॉपी-ऑन-राइट), तुरंत बनते हैं, तुरंत पुनर्स्थापित होते हैं। मैं 24 घंटे के प्रतिधारण के साथ हर 15 मिनट में rpool/data के स्वचालित स्नैपशॉट रखता हूं, साथ ही एक सप्ताह के प्रतिधारण के साथ दैनिक। zfs-auto-snapshot का उपयोग किया जाता है। "ओह, मैंने अभी प्रोडक्शन डीबी को हटा दिया" से सुरक्षा:

1apt install zfs-auto-snapshot
2# इसके बाद यह cron के माध्यम से frequent/hourly/daily/weekly/monthly बनाता है

स्तर 2 — उसी होस्ट पर एक अलग LXC में Proxmox Backup Server। ये vzdump के माध्यम से VM/LXC के पूर्ण वृद्धिशील बैकअप हैं, जो चंक स्तर पर डुप्लिकेट किए गए हैं। PBS ZFS के एक अलग डेटासेट में स्नैपशॉट संग्रहीत करता है, उन्हें एक भंडार के रूप में देखता है, प्रत्येक VM की अपनी वृद्धिशील श्रृंखला होती है।

Proxmox में कॉन्फ़िगरेशन: Datacenter → Backup → Add। अनुसूची: हर दिन 4 बजे, प्रतिधारण keep-daily=7 keep-weekly=4 keep-monthly=3। यह सब माउस से।

उसी होस्ट पर LXC में PBS रखना - एक समझौता। प्लस: एक अलग मशीन की आवश्यकता नहीं है, बैकअप localhost पर चलता है, गति स्थानीय SSD जैसी होती है, प्रतिधारण/डुप्लीकेशन पूरी तरह से काम करता है। माइनस: यदि समर्पित सर्वर पूरी तरह से मर जाता है - तो बैकअप भी मर जाते हैं। इसलिए है...

स्तर 3 — PBS रिपॉजिटरी को ऑफसाइट S3 में सिंक्रनाइज़ करना। PBS S3-संगत स्टोरेज में sync job कर सकता है। मैं हर रात Selectel के S3 (कोई भी - Backblaze, Wasabi, Cloudflare R2) में एक अलग बकेट पर स्नैपशॉट अपलोड करता हूं। वहां प्रतिधारण - दो सप्ताह, क्योंकि अधिक की आवश्यकता नहीं है: दीर्घकालिक के लिए, स्थानीय PBS है, और ऑफसाइट - "पूरा डेटा सेंटर जल गया" के लिए बीमा है।

स्तर 4 — अनुप्रयोग डेटा अलग से। Discourse अपने आप अपने बैकअप बनाता है और उन्हें S3 में रखता है (यह इसकी मूल विशेषता है)। इसलिए मेरे पास PBS और यहां तक ​​कि पूरा समर्पित सर्वर गायब होने पर भी, मेरे पास अभी भी उनके क्लाउड में Discourse के सुसंगत डंप हैं।

1# PBS से पूरे VM को पुनर्स्थापित करना - सचमुच एक कमांड:
2pvesm list backup-pbs    # क्या उपलब्ध है देखें
3qmrestore backup-pbs:backup/vzdump-qemu-201-2026_04_06-04_00_03.vma.zst 999 \
4  --storage local-zfs
5# और एक मिनट के बाद आपके पास 4 बजे के VM की कॉपी VMID 999 पर चलती है।

यह एक महत्वपूर्ण बिंदु है: बैकअप जिन्हें आपने पुनर्स्थापित करने का प्रयास नहीं किया है - वे बैकअप नहीं हैं। मैं महीने में एक बार एक खाली VMID पर एक यादृच्छिक VM का परीक्षण पुनर्स्थापना करता हूं, जांचता हूं कि यह उठता है, कि इसमें एप्लिकेशन काम करता है, और इसे हटा देता हूं। यह उबाऊ है, लेकिन एक बार इसी तरह मैंने पाया कि एक क्रॉन /tmp/... में लिख रहा था, जिसे बैकअप के दौरान छोड़ दिया जाता है, और एप्लिकेशन पुनर्स्थापना के बाद एक मैन्युअल चरण की आवश्यकता होती है।

निगरानी

जब मेरे पास 15 मशीनें हों तो Prometheus + Grafana + Alertmanager + Loki जैसे कॉम्बो इकट्ठा करना मुझे पसंद नहीं है। इसलिए मैंने तीन हल्के उपकरणों पर रोक लगा दी, सभी एक LXC में:

• Beszel — प्रत्येक VM पर एजेंटों से मेट्रिक्स एकत्र करता है (CPU, RAM, डिस्क, नेटवर्क इंटरफेस, Docker कंटेनर)। हब LXC में रहता है, एजेंट - प्रत्येक VM/LXC पर systemd यूनिट के माध्यम से। Beszel का अपना प्रमाणीकरण है, PocketBase के माध्यम से, जो कभी-कभी असुविधाजनक होता है (नीचे ग्राब्ले के बारे में) लेकिन आम तौर पर काम करता है।
• Uptime Kuma — HTTP/HTTPS/Ping/TCP के माध्यम से जांच। मेरे पास सभी सार्वजनिक (डोमेन), सभी आंतरिक सेवाओं (NetBird के माध्यम से), और मेश पर सभी नोड्स के पिंग हैं। अलर्ट - Telegram में।
• Homarr — सभी एडमिनिस्ट्रेटिव के लिंक के साथ स्टार्ट पेज। PBS UI, Dokploy UI, Vaultwarden UI किस पोर्ट पर है, इसे याद रखने की आवश्यकता नहीं है। बस Homarr खोलें और क्लिक करें।

सभी तीन एक Docker कंपोज़ में, एक LXC में, केवल NetBird के माध्यम से उपलब्ध हैं।

Beszel के साथ ग्राब्ले, ताकि आप ठोकर न खाएं: Beszel के PocketBase में दो उपयोगकर्ता तालिकाएँ हैं - _superusers (CLI/API के लिए) और users (वेब इंटरफ़ेस के लिए)। यदि आप CLI superuser upsert के माध्यम से पासवर्ड रीसेट करते हैं - तो आप केवल _superusers को रीसेट करते हैं, और UI में आप users के माध्यम से लॉग इन करते हैं और पासवर्ड मेल नहीं खाता। यह REST API के माध्यम से /api/collections/users/records/<id> पर PATCH अनुरोध द्वारा ठीक किया जाता है।

अंत में मुझे क्या मिला

लगभग तीन सप्ताह के माइग्रेशन के बाद, जब अंतिम सेवाएं बस गईं, तो मैंने एक सीमा रेखा खींची:

जो मुझे सबसे ज्यादा भावनात्मक रूप से मिला - मैंने कुछ भी छूने से डरना बंद कर दिया। कोई भी खतरनाक क्रिया (अपडेट, माइग्रेशन, प्रयोग) अब एक स्नैपशॉट से शुरू होती है और या तो कमिट या 30 सेकंड में रोलबैक के साथ समाप्त होती है। मैंने नए को आज़माने के लिए अधिक बार शुरू किया, क्योंकि त्रुटि की कीमत एक परिमाण से कम हो गई।

चेकलिस्ट, यदि आप दोहराने जा रहे हैं

यदि आप खुद को उन्हीं लक्षणों को पकड़ते हैं जैसे मैंने, तो यह देखने के लिए कि किस क्रम में आगे बढ़ना है, यह एक छोटी चेकलिस्ट है:

1. सभी VPS की कुल लागत की गणना करें, और OVH/Hetzner/LeaseWeb पर समर्पित सर्वर की कीमतों से तुलना करें। आप आश्चर्यचकित होंगे।
2. यदि ZFS की योजना बना रहे हैं तो ECC RAM लें। बचत न करें।
3. कम से कम दो डिस्क को मिरर में लें। एक डिस्क - प्रोडक्शन के लिए विकल्प नहीं है।
4. KVM/IPMI के माध्यम से Proxmox स्थापित करें, debootstrap के माध्यम से नहीं। कम दर्द।
5. तुरंत SSH कुंजी, गैर-मानक पोर्ट, पासवर्ड अक्षम, fail2ban स्थापित करें।
6. तुरंत ZFS ARC को सीमित करें। डिफ़ॉल्ट रूप से, यह आधी RAM खा जाएगा।
7. NAT के साथ निजी नेटवर्क के लिए एक दूसरा ब्रिज vmbr1 बनाएं। सभी VM/LXC वहां। वर्चुअल मशीनों पर कोई सार्वजनिक IP नहीं।
8. NetBird (या Tailscale, या Headscale) को माइग्रेट करना शुरू करने से पहले उठाएं। यह आपका माइग्रेशन चैनल और एडमिन एक्सेस है।
9. Proxmox UI को बाहर न खोलें। केवल VPN-मेश के माध्यम से।
10. एक अलग प्रदाता से TLS टर्मिनेशन और ब्लॉक बाईपास के लिए एक छोटा आउटगोइंग VPS - वैकल्पिक है, लेकिन बहुत सुविधाजनक है। कीमत मामूली है, लाभ बहुत हैं।
11. अलग LXC में PBS + ऑफसाइट S3 सिंक। बैकअप स्वचालित होना चाहिए।
12. कम से कम महीने में एक बार परीक्षण पुनर्स्थापना करें। अन्यथा, आपके पास बैकअप नहीं, बल्कि आत्म-आश्वासन के लिए फ़ाइलें हैं।
13. एक समय में एक सेवा को माइग्रेट करें, महत्व के क्रम में। "सप्ताहांत में सब कुछ स्थानांतरित करने" की कोशिश न करें।
14. स्विचिंग से एक दिन पहले DNS पर TTL कम करें, एक घंटे पहले नहीं।
15. प्रत्येक सेवा के लिए दस्तावेज़ रखें: कॉन्फ़िगरेशन कहाँ है, कैसे शुरू करें, कैसे बैकअप करें, कैसे पुनर्स्थापित करें। छह महीने बाद, आप खुद को धन्यवाद देंगे।

क्या बचा है

पूर्णता के लिए: मेरा माइग्रेशन अभी 100% पूरा नहीं हुआ है। बचा है:

• पुराने सर्वर से कुछ Remnawave पैनल (अगले सप्ताहांत के लिए नियोजित)।
• Caddy को प्लगइन्स के साथ माइग्रेट करना (एक कस्टम बिल्ड है), यह फिलहाल अस्थायी रूप से काम कर रहा है।
• पुराना CrowdSec - अलग से खरोंच से डाल रहा हूं, माइग्रेट नहीं कर रहा हूं।

लेकिन सब कुछ महत्वपूर्ण (फोरम, बिलिंग, बॉट, डेटाबेस) - पहले से ही समर्पित सर्वर पर है, स्थिर रूप से काम कर रहा है, बैकअप और मॉनिटर किया जा रहा है।

Open

यदि आपके पास विशिष्ट चरणों, कॉन्फ़िगरेशन या उन ग्राब्ले पर प्रश्न हैं जिन पर मैंने ठोकर खाई है - टिप्पणियों में लिखें, मैं विस्तार से समझाने की कोशिश करूंगा। विशेष रूप से यह सुनना दिलचस्प है कि आप अन्य हाइपरवाइजर (XCP-ng, ESXi, या बिल्कुल प्लेन Docker Swarm) पर समान समस्याओं को कैसे हल करते हैं - शायद मैं कुछ चूक रहा हूं।

आपके इंफ्रास्ट्रक्चर को समेकित करने में शुभकामनाएँ। कम बिल, अधिक नियंत्रण - यह इसके लायक है।