DigitalOcean से Hetzner पर माइग्रेट करना

 (isayeter.com)
17 पॉइंट द्वारा GN⁺ 13 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मासिक $1,432 की production infrastructure को मासिक $233 dedicated server पर ले जाते हुए, operating system तक बदलने के बावजूद बिना downtime के service continuity बनाए रखी गई
  • 30 MySQL databases और 34 Nginx virtual hosts, GitLab EE, Neo4J, Supervisor, Gearman को नए server पर समान रूप से configure करने के बाद real-time replication और अंतिम incremental sync के जरिए migration पूरा किया गया
  • database migration की कुंजी mydumper·myloader parallel processing और MySQL replication का संयोजन था, और MySQL 5.7 से 8.0 में upgrade करते समय आए sys schema और permissions issues भी ठीक किए गए
  • cutover DNS TTL कम करना, पुराने server के Nginx reverse proxy conversion, और A records को bulk में बदलने के क्रम से किया गया, ताकि DNS propagation के दौरान भी पुराने IP पर आने वाले requests नए server तक पहुँचते रहें
  • नतीजतन मासिक $1,199 की बचत, वार्षिक $14,388 की बचत, CPU·memory·storage upgrade और 0 मिनट downtime एक साथ हासिल किए गए

माइग्रेशन की पृष्ठभूमि

  • तुर्की में software company चलाने के संदर्भ में तेज़ inflation और तुर्की लीरा की कमजोरी के कारण dollar आधारित infrastructure cost का बोझ काफ़ी बढ़ गया था
  • मौजूदा DigitalOcean server की लागत हर महीने $1,432 थी, और configuration में 192GB RAM, 32 vCPU, 600GB SSD, 1TB block volume 2 units, और backups शामिल थे
  • नया target Hetzner AX162-R dedicated server था, जिसमें AMD EPYC 9454P 48-core 96-thread, 256GB DDR5, 1.92TB NVMe Gen4 RAID1 configuration था
  • मासिक लागत घटकर $233 रह गई, और मासिक बचत $1,199, वार्षिक बचत $14,388 हुई
  • मौजूदा server की reliability या developer experience से कोई शिकायत नहीं थी, लेकिन steady-state workloads में price-to-performance अब व्यावहारिक नहीं रह गया था

मौजूदा production environment

  • operating stack कोई साधारण test environment नहीं बल्कि वास्तविक production environment था
    • MySQL databases 30, कुल 248GB data
    • कई domains पर फैले Nginx virtual hosts 34
    • GitLab EE backups 42GB सहित
    • Neo4J Graph DB 30GB scale पर चल रहा था
    • Supervisor से दर्जनों background workers manage किए जा रहे थे
    • Gearman job queue उपयोग में था
    • सैकड़ों हज़ार users के लिए live mobile apps चल रही थीं
  • मौजूदा server का operating system CentOS 7 था, जो पहले ही end-of-support स्थिति में था
  • नए server का operating system AlmaLinux 9.7 है, जो RHEL 9 compatible distribution और CentOS का स्वाभाविक successor विकल्प है
  • यह migration सिर्फ cost saving नहीं था, बल्कि कई वर्षों से security updates न पाने वाले operating system से बाहर निकलने का अवसर भी था

zero-downtime strategy

  • सिर्फ DNS बदलकर service restart करने वाला तरीका स्वीकार नहीं किया गया, बल्कि 6-step migration procedure के साथ zero-downtime migration किया गया

  • चरण 1: नए server पर पूरा stack install करना

    • Nginx को पुराने server के समान flags के साथ source compile करके install किया गया
    • PHP को Remi repo के ज़रिए install किया गया और पुराने server की वही .ini configuration files लागू की गईं
    • MySQL 8.0, Neo4J Graph DB, GitLab EE, Node.js, Supervisor, Gearman install कर पुराने behavior के अनुरूप configure किया गया
    • DNS records छूने से पहले सभी services को पुराने server की तरह ही काम करने की स्थिति में लाया गया
    • SSL certificates को पुराने server की पूरी /etc/letsencrypt/ directory को rsync से copy करके संभाला गया
    • पूरा traffic नए server पर जाने के बाद certbot renew --force-renewal से certificates को bulk में force renew किया गया

  • चरण 2: web files की rsync replication

    • /var/www/html पूरी directory, लगभग 65GB, 15 लाख files को SSH आधारित rsync से replicate किया गया
    • --checksum option के साथ integrity verification किया गया
    • cutover से ठीक पहले बदली हुई files के लिए अंतिम incremental sync भी किया गया

  • चरण 3: MySQL master-slave replication

    • dump और restore के लिए databases को बंद करने के बजाय real-time replication सेट की गई
    • पुराने server को master और नए server को read-only slave के रूप में सेट किया गया
    • शुरुआती बड़े data load के लिए mydumper इस्तेमाल हुआ, फिर dump metadata में दर्ज सटीक binlog position से replication शुरू की गई
    • cutover तक दोनों databases को real-time sync स्थिति में रखा गया

  • चरण 4: DNS TTL कम करना

    • DigitalOcean DNS API को script से call कर सभी A/AAAA record TTL को 3600 seconds से 300 seconds पर लाया गया
    • MX, TXT records नहीं बदले गए
    • mail record TTL बदलने से deliverability issues हो सकते थे, इसलिए उन्हें बाहर रखा गया
    • मौजूदा TTL के विश्व स्तर पर expire होने के लिए 1 घंटा इंतज़ार किया गया, फिर 5 मिनट के भीतर cutover की तैयारी पूरी हो गई

  • चरण 5: पुराने server के Nginx को reverse proxy में बदलना

    • Python script ने 34 Nginx site configurations में server {} blocks को parse किया
    • पुराने configs backup किए गए और उन्हें नए server की ओर इशारा करने वाले proxy configs से बदल दिया गया
    • DNS propagation के दौरान भी पुराने IP पर आने वाले requests चुपचाप नए server तक forward होते रहे
    • user के नज़रिए से किसी interruption का अनुभव नहीं हुआ

  • चरण 6: DNS cutover और पुराने server को बंद करना

    • Python script से DigitalOcean API call कर सभी A records को कुछ seconds में नए server IP पर बदला गया
    • पुराने server को 1 हफ़्ते तक cold standby में रखा गया और फिर बंद किया गया
    • पूरी प्रक्रिया के दौरान service या तो सीधे respond करती रही या proxy के ज़रिए, इसलिए availability gap का कोई चरण नहीं आया

MySQL migration

  • पूरे काम में सबसे जटिल हिस्सा MySQL migration था

  • data dump

    • standard mysqldump के बजाय mydumper इस्तेमाल किया गया
    • नए server के 48 CPU cores का उपयोग कर parallel export/import से single-threaded mysqldump के हिसाब से कई दिनों का काम कुछ घंटों में पूरा हुआ
    • उपयोग किए गए मुख्य options में --threads 32, --compress, --trx-consistency-only, --skip-definer, --chunk-filesize 256 शामिल थे
    • main dump की metadata file में snapshot समय का binlog position दर्ज था
      • File: mysql-bin.000004
      • Position: 21834307
    • यही मान बाद में replication start point के रूप में उपयोग हुए

  • dump transfer

    • dump पूरा होने के बाद SSH आधारित rsync से इसे नए server पर भेजा गया
    • कुल 248GB compressed chunks transfer हुए
    • mydumper के --compress option ने compressed chunks के कारण network transfer speed बेहतर करने में मदद की

  • data load

    • myloader इस्तेमाल किया गया
    • मुख्य options थे --threads 32, --overwrite-tables, --ignore-errors 1062, --skip-definer

  • MySQL 5.7 से 8.0 में transition issues

    • CentOS 7 environment की वजह से पुराना server MySQL 5.7 पर अटका हुआ था
    • migration से पहले mysqlcheck --check-upgrade से data की MySQL 8.0 compatibility जाँची गई, और result में कोई issue नहीं मिला
    • नए server पर नवीनतम MySQL 8.0 Community install किया गया
    • पूरे project में query execution time काफ़ी कम हुआ, और मूल लेख में इसका कारण MySQL 8.0 का improved optimizer और InnoDB enhancements बताया गया
    • लेकिन version jump के कारण समस्याएँ भी आईं
      • import के बाद mysql.user table की column structure अपेक्षित 51 columns के बजाय 45 columns थी
      • इसके परिणामस्वरूप mysql.infoschema गायब था और user authentication issues आए
    • पहला fix attempt नीचे दिए गए commands से किया गया
      • systemctl stop mysqld
      • mysqld --upgrade=FORCE --user=mysql &
    • पहला प्रयास ERROR: 'sys.innodb_buffer_stats_by_schema' is not VIEW error के साथ fail हुआ
    • कारण यह था कि sys schema view की जगह सामान्य table के रूप में import हो गया था
    • समाधान DROP DATABASE sys; चलाकर upgrade दोबारा करना था
    • इसके बाद प्रक्रिया सामान्य रूप से पूरी हो गई

MySQL replication configuration

  • दोनों servers पर dump load पूरा होने के बाद, नए server को पुराने server का replica बनाया गया
  • CHANGE MASTER TO statement में पुराने server का IP, replication user, port 3306, MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=21834307 सेट किया गया
  • इसके बाद START SLAVE; चलाया गया
  • लगभग तुरंत error 1062 Duplicate Key के कारण replication रुक गई
  • कारण यह था कि dump दो हिस्सों में किया गया था और इस बीच कुछ tables पर writes हुईं, इसलिए imported dump और binlog replay ने एक ही rows को duplicate insert करने की कोशिश की
  • समाधान के लिए नीचे की setting लागू की गई
    • SET GLOBAL slave_exec_mode = 'IDEMPOTENT';
    • START SLAVE;
  • IDEMPOTENT mode duplicate key और missing row errors को चुपचाप skip कर देता है
  • सभी critical databases बिना errors के sync हो गए, और कुछ ही मिनटों में Seconds_Behind_Master value 0 तक घट गई

cutover से पहले verification

  • DNS records बदलने से पहले नए server पर सभी services सही चल रही हैं या नहीं, यह verify करना ज़रूरी था
  • verification method यह था कि local machine की /etc/hosts file को अस्थायी रूप से बदलकर domain को नए server IP पर map किया गया
  • browser और Postman नए server पर requests भेजते थे, जबकि बाहरी users अभी भी पुराने server से जुड़ते रहे
  • API endpoints, admin panel, और हर service के response status की जाँच की गई
  • सब कुछ confirm होने के बाद वास्तविक cutover किया गया

SUPER privilege issue

  • master-slave replication पूरी तरह sync होने के बाद भी नए server पर read_only = 1 रहते हुए INSERT statements सफल हो रहे थे
  • कारण यह था कि सभी PHP application users को SUPER privilege दिया गया था
  • MySQL में SUPER privilege read_only को bypass कर देता है
  • SHOW GRANTS FOR 'some_db_user'@'localhost'; के result में SUPER privilege शामिल होना confirm हुआ
  • कुल 24 application users के लिए बार-बार REVOKE SUPER ON *.* FROM 'some_db_user'@'localhost'; चलाया गया
  • इसके बाद FLUSH PRIVILEGES; किया गया
  • उसके बाद read_only = 1 ने application user writes को सही ढंग से block करना शुरू किया, जबकि replication जारी रही

DNS preparation

  • सभी domains DigitalOcean DNS से manage किए जा रहे थे, और nameservers GoDaddy पर connected थे
  • TTL कम करने का काम DigitalOcean API के लिए script किया गया
  • बदलाव केवल A, AAAA records तक सीमित थे
  • MX, TXT records को नहीं छुआ गया
    • Google Workspace deliverability issues की संभावना के कारण mail-related record TTL changes बाहर रखे गए
  • पुराने TTL के expire होने के लिए 1 घंटा इंतज़ार कर cutover की तैयारी पूरी की गई

पुराने server के Nginx को reverse proxy में बदलना

  • 34 config files को manually edit करने के बजाय Python script से automatic conversion किया गया
  • script ने सभी config files के server {} blocks को parse किया, core content block पहचाना और उसे proxy settings से replace किया
  • मूल settings को .backup files के रूप में backup किया गया
  • example configuration में proxy_pass https://NEW_SERVER_IP;, proxy_set_header Host $host;, proxy_set_header X-Real-IP $remote_addr;, proxy_read_timeout 150; लागू किए गए
  • महत्वपूर्ण option था proxy_ssl_verify off
    • क्योंकि नए server का SSL certificate domain के लिए valid था, IP address के लिए नहीं
    • दोनों endpoints पर नियंत्रण होने की वजह से यहाँ verification disable करना स्वीकार्य था

cutover procedure

  • cutover से ठीक पहले की शर्तें थीं कि replication lag Seconds_Behind_Master: 0 हो और reverse proxy तैयार हो
  • execution order इस प्रकार था
    • नए server पर STOP SLAVE;
    • नए server पर SET GLOBAL read_only = 0;
    • नए server पर RESET SLAVE ALL;
    • नए server पर supervisorctl start all
    • पुराने server पर nginx -t && systemctl reload nginx चलाकर proxy activate करना
    • पुराने server पर supervisorctl stop all
    • local Mac से python3 do_cutover.py चलाकर DNS के सभी A records को नए server IP पर बदलना
    • लगभग 5 मिनट propagation का इंतज़ार
    • पुराने server पर सभी crontab entries को comment करना
  • DNS cutover script ने DigitalOcean API call कर सभी A records को लगभग 10 seconds में बदल दिया

cutover के बाद अतिरिक्त काम

  • migration पूरा होने के बाद पाया गया कि कई GitLab project webhooks अब भी पुराने server IP की ओर इशारा कर रहे थे
  • GitLab API के जरिए सभी projects को scan करके webhooks को bulk में update करने वाली script लिखी और लागू की गई

अंतिम परिणाम

  • मासिक लागत $1,432 से घटकर $233 रह गई
  • वार्षिक बचत $14,388 हुई
  • performance के लिहाज़ से भी अधिक शक्तिशाली server मिला
    • CPU 32 vCPU से बढ़कर 96 logical CPU हो गया
    • RAM 192GB से बढ़कर 256GB DDR5 हो गई
    • storage लगभग 2.6TB mixed configuration से 2TB NVMe RAID1 में बदल गया
    • downtime 0 मिनट रहा
  • पूरा migration लगभग 24 घंटे में पूरा हुआ
  • users पर कोई प्रभाव नहीं पड़ा

मुख्य सीख

  • MySQL replication zero-downtime migration का मुख्य साधन है
    • इसे शुरुआत में सेट करके पर्याप्त catch-up समय देने के बाद cutover करना प्रभावी रहा
  • MySQL user privileges की migration से पहले ज़रूर जाँच करनी चाहिए
    • SUPER privilege होने पर read_only bypass हो जाता है, जिससे slave environment वास्तव में read-only नहीं रहता
  • DNS updates, Nginx config changes, और webhook fixes को script करना महत्वपूर्ण है
    • 34 से अधिक sites को manually संभालने पर समय ज़्यादा लगता है और errors की संभावना बढ़ती है
  • mydumper + myloader का संयोजन बड़े datasets में mysqldump से कहीं तेज़ है
    • 32-thread parallel dump और restore ने कई दिनों का काम कुछ घंटों में बदल दिया
  • steady-state workloads में cloud provider महँगा पड़ सकता है, और dedicated server कम लागत पर ज़्यादा performance दे सकता है

GitHub scripts

  • migration में इस्तेमाल की गई सभी Python scripts को GitHub पर public किया गया
  • शामिल scripts की सूची
    • do_list_domains_ttl.py
      • सभी DigitalOcean domains के A records, IP, TTL की query
    • do_ttl_update.py
      • सभी A/AAAA records का TTL bulk में 300 seconds पर लाना
    • do_to_hetzner_bulk_dns_records_import.py
      • सभी DNS zones को DigitalOcean से Hetzner DNS में migrate करना
    • do_cutover_to_new_ip.py
      • सभी A records को पुराने server IP से नए server IP पर switch करना
    • nginx_reverse_proxy_update.py
      • सभी nginx site configs को reverse proxy configs में convert करना
    • mysql_compare.py
      • दोनों MySQL servers में सभी tables के row count की तुलना करना
    • final_gitlab_webhook_update.py
      • सभी GitLab project webhooks को नए server IP पर update करना
    • mydumper
      • mydumper library
  • सभी scripts DRY_RUN = True mode को support करती हैं, जिससे वास्तविक apply से पहले सुरक्षित preview संभव है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 13 일 전
Hacker News की राय

  • कुछ महीने पहले मैंने दो सर्वर Linode और DO से Hetzner पर शिफ्ट किए, और लागत में काफ़ी बड़ी बचत हुई। इससे भी ज़्यादा प्रभावशाली बात यह थी कि वहाँ दर्जनों साइटें थीं, अलग-अलग भाषाएँ, पुराने libraries, MySQL और Redis तक के साथ एकदम बिखरा हुआ stack बना हुआ था। लेकिन Claude Code ने यह सब माइग्रेट कर दिया, और जहाँ library नहीं मिली वहाँ कुछ code फिर से लिखकर काम पूरा किया। अब ऐसी जटिल migrations काफ़ी आसान हो गई हैं, इसलिए लगता है आगे providers के बीच portability और बढ़ेगी

    • मेरे हिसाब से लोग जादुई compute के लिए पैसे नहीं दे रहे थे, बल्कि 10 साल में जोड़ा गया glue code छेड़ना न पड़े इसके लिए दे रहे थे। लेकिन अगर agents उस glue को ही खा जाना शुरू कर दें, तो मौजूदा providers का moat जल्दी पतला हो सकता है
    • सच कहूँ तो यह Claude ad के अंदर Hetzner ad जैसा लगा। अब बस सोच रहा हूँ कि यह nesting आखिर कहाँ तक जाती है
    • मुझे नहीं लगता कि हर बात को ज़रूरी तौर पर AI की चर्चा में बदलना चाहिए
    • मैं भी अगले कुछ महीनों में Linode छोड़ने वाला हूँ। 10 साल से ज़्यादा इस्तेमाल किया और काफ़ी customers भी refer किए, लेकिन उन्होंने दाम बढ़ाते-बढ़ाते अब यह हाल कर दिया है कि Hetzner जैसी जगह पर उससे सस्ता लेकर 8x memory, dedicated NVMe, और dedicated CPU मिल सकता है। virtual servers की आसान portability जैसे कुछ फायदे कम हो जाते हैं, लेकिन outage होने पर भी Hetzner support हमेशा तेज़ और सक्षम रहा है
    • मैं भी Claude को धीरे-धीरे DevOps में ज़्यादा इस्तेमाल कर रहा हूँ। अपने bare metal पर Proxmox से VMs चलाता हूँ, और Claude ने कई machines में फैले नए network को बहुत तेज़ी से optimize और configure कर दिया, इसलिए वह लगभग किसी सहकर्मी या अच्छे-खासे paid sysadmin जैसा लगता है

  • मैं AWS से Hetzner पर जाने की योजना बना रहा हूँ। Amazon कभी-कभी competitors से 20 गुना महँगा pricing रखता है, ठीक-ठाक price पाने के लिए long-term commitment पर ज़ोर देता है, और data transfer को भी बहुत महँगा बनाकर रखता है, जो मुझे काफ़ी customer-hostile लगता है। वे शायद सोचते हों कि egress fees से लोग फँसे रहेंगे, लेकिन असल में होता यह है कि अगर आप एक हिस्सा भी competitor के पास ले जाएँ तो दबाव पूरे stack को ही बाहर ले जाने का बनता है। फिर भी मेरे लिए migration थोड़ा आसान है क्योंकि मैंने platform Amazon-specific services के ऊपर नहीं बनाया

    • यह बात पहले सही थी, लेकिन जनवरी 2024 में GCP ने egress cost waiver policy निकाली, और कुछ महीनों बाद AWS ने भी ऐसी ही policy ला दी। मैं आपको वहीं रुकने के लिए मनाने की कोशिश नहीं कर रहा, बस तकनीकी तौर पर waiver request संभव है यह कहना चाहता हूँ। असल में कितना कवर होता है, यह मुझे भी पक्का नहीं पता, और AWS की wording देखकर EU Data Act का असर भी लगता था

  • ऐसे पोस्ट हर बार देखने पर मुझे हैरानी होती है कि लोग redundancy या load balancer जैसी बातों का ज़्यादा ज़िक्र नहीं करते। अगर एक server मर जाए तो कई services एक साथ नीचे जा सकती हैं, तो क्या लोग सच में इसे ठीक मानते हैं? हो सकता है आपने पैसे बचाए हों, लेकिन maintenance time और भविष्य की दिक्कतें बढ़ जाएँ

    • मुझे लगता है यह service के nature और उसकी criticality पर निर्भर करता है। अगर एक server 10 साल चले और उस दौरान कुल 1 हफ़्ते से 1 महीने तक downtime रहे, तो बहुत-सी situations में यह स्वीकार्य हो सकता है। छोटे business, hobby sites, forums, blogs जैसी जगहों पर जहाँ website core business नहीं है, वहाँ छोटा downtime बड़ा issue नहीं होता। सच कहें तो low-traffic sites की यही long tail शायद web का बड़ा हिस्सा है। हर चीज़ को high availability की ज़रूरत नहीं होती, और अगर चाहिए तो ऐसे providers भी load balancer जैसी सुविधाएँ देते हैं
    • मुझे लगता है ऐसे पोस्ट इसलिए popular होते हैं क्योंकि इनमें अक्सर requirements और solution का mismatch दिखता है। अगर किसी hobby project या छोटे business पर enterprise-grade architecture चढ़ाकर overengineering की गई हो, तो शायद कभी-कभार एक दिन का downtime ठीक हो और full cloud setup ज़रूरी न हो। लेकिन इस पोस्ट में थोड़ा अजीब यह लगा कि इसने zero-downtime migration पर ज़ोर दिया, जबकि अंत में जो architecture पहुँचा वह failure-tolerant ज़्यादा नहीं दिखा। Hetzner पर थोड़ा-सा और structure जोड़ते तो यह काफ़ी बेहतर हो सकता था
    • बहुत-से workloads को उस स्तर की तैयारी की ज़रूरत ही नहीं होती। और simplicity की reliability को कम नहीं आँकना चाहिए। मैं लंबे समय तक Linux sysadmin रहा हूँ, और जटिल systems में simple systems की तुलना में कहीं ज़्यादा downtime देखा है। theory और reality के बीच कहीं, मेरा अनुभव यही रहा कि ज़्यादातर मामलों में simple setup ही ज़्यादा टिकता है
    • निष्पक्ष तौर पर देखें तो वे पहले भी DigitalOcean का single VM ही इस्तेमाल कर रहे थे, इसलिए cloud provider के फायदों का भरपूर लाभ मिल ही नहीं रहा था। आम तौर पर ऐसे पोस्ट दो तरह के होते हैं: एक जहाँ लोग cloud पर ग़लत कारणों से गए और physical setup पर जाना सही बैठता है, और दूसरा जहाँ ऐसा shift disaster बन जाता है। यह मामला पहले वाले जैसा लगता है। अगर setup DO पर ठीक चल रहा था, तो Hetzner पर भी सही DR policy के साथ ठीक रहना चाहिए
    • हो सकता है यह फ़ैसला उस अनुभव पर आधारित हो जहाँ उन्होंने सच में लंबे समय का maintenance hell या भविष्य की मुसीबतें ज़्यादा झेली ही न हों

  • हमने lithus.eu पर कई बार customers को अलग-अलग clouds से Hetzner पर migrate किया है। आम तौर पर multi-server, कभी-कभी multi-AZ setup बनाते हैं, और Kubernetes से workloads बाँटकर HA देते हैं। single node के लिए Kubernetes overkill हो सकता है, लेकिन nodes कई हों तो यह काफ़ी समझदारी भरा हो जाता है। backups के लिए Velero और application-level backups साथ में इस्तेमाल करते हैं, और जैसे Postgres के लिए WAL backups से PITR तक ले जाते हैं। stateful data कम-से-कम दो nodes पर रखते हैं ताकि HA बना रहे। performance के मामले में भी bare metal आम तौर पर बेहतर रहा, और AWS की तुलना में response time कई बार आधा हो गया। इसका कारण virtualisation से ज़्यादा NVMe, कम network latency, और कम cache contention जैसे आसपास के factors लगे। इससे जुड़ी और बातें मैंने पहले लिखे HN पोस्ट में भी डाली थीं

    • मैंने भी कुछ साल पहले खुद measurements किए थे, और उसके बाद virtual servers की तरफ़ वापस नहीं देखा। CPU time RAM की तरह reserve नहीं होता, इसलिए असली hardware के मुकाबले performance सच में बहुत खराब थी। यह benchmark post भी देखने लायक थी
    • मुझे लगता है k8s deployments portability के लिए बहुत अच्छे होते हैं। अलग-अलग clouds की managed services की तुलना में इनमें vendor lock-in कम होता है। मेरा stack भी k8s, hosted Postgres, और s3-टाइप storage जैसा ही है, इसलिए Postgres को तो कभी भी self-host किया जा सकता है और आखिर में core dependency बस k8s और s3 जैसी चीज़ें ही बचती हैं। लगता है Hetzner के पास भी s3 जैसी कुछ चीज़ है, लेकिन मैंने अभी नहीं देखा, और 100TB माइग्रेट करना काफ़ी बड़ा काम होगा
    • जानकारी के लिए, HA का मतलब high availability है
    • पोस्ट समझदारी भरी थी, लेकिन आखिर में email डाल देना थोड़ा promotional copy जैसा लगा, जो अच्छा नहीं लगा

  • यह पोस्ट पढ़ना काफ़ी मुश्किल था। ऐसा लगा जैसे Claude ने migration किया और फिर Claude ने ही report लिख दी। अगर LLM की वजह से इतनी बचत हुई तो वह शानदार बात है, लेकिन अगर आप उसे public post की तरह डाल रहे हैं तो कम-से-कम edit करके repetition और LLM-जैसी writing साफ़ कर देनी चाहिए

    • मुझे पता है कि बहुत-से लोग original पढ़ते ही नहीं, लेकिन इस बार सच में यह दर्दनाक स्तर तक मुश्किल था

  • मुझे लगता है Hetzner के साथ सावधानी रखनी चाहिए। पहले मुझे वह बहुत पसंद था, लेकिन हाल में वहाँ से निकल आया। हमारे CI/CD pipeline में इस्तेमाल हो रही लगभग 30 VMs उन्होंने एक $36 billing dispute पर सब बंद कर दीं। हमने bank records तक के साथ पूरा payment proof दिया, लेकिन उन्होंने देखना भी नहीं चाहा, और emergency में संपर्क करने के दौरान भी अंत में सारा access बंद कर दिया। अब हम Scaleway पर हैं

    • customer service उम्मीद से ज़्यादा hostile लगी। फिर भी गैर-ज़रूरी कामों के लिए मैं अब भी उसे इस्तेमाल करता हूँ
    • Hetzner की billing handling काफ़ी automated है, लेकिन आम तौर पर card payment fail होने पर वे लगभग एक महीने का grace period देते रहे हैं

  • कुछ महीने पहले मैं एक छोटे SaaS side project के लिए AWS alternatives देख रहा था, और cost savings व EU cloud support की वजह से शुरू में Hetzner को गंभीरता से देखा। ज़्यादा चीज़ें खुद करनी पड़ेंगी यह भी मंज़ूर था, लेकिन आख़िरकार IP reputation सबसे बड़ी रुकावट बनी। हमारी company के managed AWS firewall rules में से एक Hetzner IPs के बड़े हिस्से, शायद लगभग सभी को block कर रहा था, और मेरे work laptop पर भी Hetzner IP पर hosted sites IT policy की वजह से नहीं खुल रही थीं। Cloudflare जैसी चीज़ें लगाएँ तो शायद असर कम हो, लेकिन DDoS protection कमजोर होने की बातें भी देखीं। आख़िर में मैंने EU region का DO App Platform चुना, और managed DB option भी बड़ा plus था

    • अगर Amazon competitors को इस तरह block कर रहा है, तो उनके नज़रिए से यह काफ़ी सुविधाजनक तरीका है
    • पता नहीं आप किस firewall rule की बात कर रहे हैं, लेकिन DO का Hetzner से ज़्यादा trusted होना मेरे लिए काफ़ी surprising है। जब मैं scrapers या hackers देखता हूँ तो DO ASN भी अक्सर दिखता है, इसलिए मुझे लगता है वह भी कभी block हो सकता है
    • मेरे अनुभव में DO IPs और भी बदतर थे। मैं भी ठीक इसी वजह से DO से हटा
    • मैंने पहले Tor वाला thread में यह मुद्दा लिखा था। मेरा अनुमान था कि Hetzner Tor-friendly होने की वजह से उसकी IP reputation प्रभावित हो सकती है, हालाँकि उस समय कुछ जवाबों में कहा गया था कि reputation issue नहीं है। लेकिन Tor Project के data को देखकर लगता है Hetzner Tor network का लगभग 7% हिस्सा है, इसलिए बात इतनी simple नहीं लगती
    • विडंबना यह है कि मैंने सिर्फ AWS और Azure block करके bot problem का 99% हल कर लिया। real users पर zero impact था, इसलिए अब सोच रहा हूँ कि शायद सिर्फ यह blocking feature ही एक service की तरह बेचना चाहिए

  • ऐसी migration experience share करना काफ़ी उपयोगी और सराहनीय लगा। मैं DO बनाम Hetzner की तुलना DoorDash या UberEats खोलने और खुद रात का खाना बनाने वाले trade-off से करता हूँ। cost ratio भी कुछ ऐसा ही लगता है। मैं तीनों बड़े clouds और on-prem सब सँभालता हूँ, लेकिन छोटे कामों या PoC testing के लिए आज भी DigitalOcean console पर चला जाता हूँ। कुछ buttons क्लिक करके server या bucket तैयार हो जाना, sane defaults मिलना, और checkbox से backups जुड़ जाना जैसी convenience की निश्चित ही value है, अगर आप समय की कीमत भी जोड़ें

    • मैं पूरी तरह आश्वस्त नहीं हूँ कि आपका मतलब क्या था, लेकिन Hetzner Console भी कुछ-कुछ ऐसा ही लगता है
    • इस पोस्ट में मेरे लिए दो बातें दिलचस्प थीं। पहली, zero-downtime migration procedure खुद, जो broadly उपयोगी reference है। दूसरी, cloud instance को bare metal से बदलने का फ़ैसला, जहाँ cost savings के साथ fast failover और backup loss का cost भी शामिल मानना चाहिए। मैं होता तो लगभग $200 और खर्च करके एक hot spare रखता, और हर कुछ दिनों में active/standby बदलकर verify करता कि दोनों सही काम कर रहे हैं। अपेक्षाकृत कम लागत में catastrophic failure का risk काफ़ी घट सकता है
    • आपने जो बताया, वह तो वास्तव में Hetzner Cloud कई सालों से देता आ रहा experience के काफ़ी करीब है। ऊपर से Hetzner Cloud API भी है, इसलिए button clicks के बिना भी सब कुछ IaC से configure किया जा सकता है
    • मेरे मामले में मैं Hetzner server के ऊपर Coolify चलाता हूँ और लगभग one-click service जैसा अनुभव पा लेता हूँ
    • यह सब पढ़कर मुझे बस यह xkcd याद आया

  • मैं जानना चाहता था कि DB backups कैसे हो रहे हैं। क्या replica या standby है, या बस hourly backups जैसी कोई चीज़? ऐसे single-server setup में अगर SSD जैसी hardware failure हो जाए तो app तुरंत रुक सकता है, और खासकर SSD मर जाए तो फिर से setup होने तक कई घंटे या कई दिन downtime हो सकता है

    • Hetzner आम तौर पर hardware servers को 2x 1TB SSD के रूप में advertise करता है, और 1TB usable space के लिए SW RAID1 setup ज़ोर देकर recommend करता है। उनका image installer भी default में उसी दिशा में जाता है। अगर कुछ साल बाद पहली SSD fail भी हो जाए, और monitoring उसे पकड़ ले, तो आप नए box पर migrate कर सकते हैं, या कोई intermediate alternative/replica इस्तेमाल कर सकते हैं, या दूसरी disk पर टिके रहकर hot-swap का इंतज़ार कर सकते हैं। बेशक physical server चुनने पर cloud की कुछ redundancy छूट जाती है, इसलिए जो बचत हो रही है उसके साथ इसे risk model में जोड़कर देखना चाहिए। और कम-से-कम remote storage पर daily backups भी न हों तो वह लापरवाही होगी। यह cloud पर भी उतना ही सही है, बस वहाँ setup आसान होता है
    • इतना लंबा downtime भी हो सकता है कि किसी को ज़्यादा फ़र्क ही न पड़े। उदाहरण के लिए, मेरा HOA mobile app एक हफ़्ते बंद रहे तो भी मुझे कोई खास परेशानी नहीं होगी। हर चीज़ के लिए हमेशा चालू रहना ज़रूरी नहीं होता
    • मुझे भी यही चिंता हुई। पोस्ट से लगा कि लेखक ने पर्याप्त सोच-विचार के बिना बस aggressive cost cutting देखा। DigitalOcean VM शायद live migration और snapshots देता होगा, लेकिन Hetzner में यह आम तौर पर केवल cloud product में मिलता है। Hetzner bare metal में अगर disk या component मर जाए तो वह सचमुच मर जाता है, और disk बदल भी दें तो recovery आपको शुरू से करनी पड़ती है। Hetzner खुद भी यह बात कई जगह साफ़ करता है
    • मेरे लिए सबसे आसान MongoDB वाला setup रहा, जहाँ replication, sharding, और failover बहुत सरल थे। हाल में PostgreSQL में भी pg_auto_failover के साथ 1 monitor, 1 primary, 1 replica का setup किया, और setup व pitfalls समझ लेने के बाद यह भी काफ़ी आसान लगा। मेरे अनुभव में zero-downtime migration भी संभव थी
    • अगर उन्होंने तय किया कि वे यह trade-off स्वीकार कर सकते हैं, तो उसे सीधे ग़लत नहीं कहा जा सकता। हर app को 24/7 availability नहीं चाहिए, और ज़्यादातर websites कुछ घंटों के downtime से बुरी तरह प्रभावित नहीं होतीं। अगर cost savings risk से बड़ी है, तो यह पूरी तरह उचित business decision हो सकता है। मुझे ज़्यादा जिज्ञासा इस बात की है कि उनकी backup/recovery strategy क्या है, और Hetzner पर जाने से उसमें क्या बदला

  • header में जो meme image थी, वह मैंने बनाई थी। उसे मैंने इस पोस्ट में इस्तेमाल किया था, और अब उसे दूसरी बार इस्तेमाल होते देखना अच्छा लगा