Memahami DNS Round Robin

 (blog.hyperknot.com)
3 poin oleh GN⁺ 2024-10-27 | 1 komentar | Bagikan ke WhatsApp
  • Operator OpenFreeMap menggabungkan beberapa VPS regional ke dalam A record pada subdomain yang sama untuk membentuk DNS round robin, lalu menguji server mana yang benar-benar dipilih oleh browser dan Cloudflare
  • Tanpa load balancer terpisah, pendekatan ini diharapkan bisa memberikan distribusi beban dan penghindaran gangguan, tetapi hasil nyatanya sangat bergantung pada cara klien mengurutkan alamat dan melakukan percobaan ulang
  • Hasil pengujian dengan 3 VPS di AS, Eropa, dan Singapura menunjukkan bahwa Chrome dan Firefox cenderung menetapkan satu server acak saat awal, sedangkan Safari dan curl setelah permintaan berulang akan mengarah ke server EU terdekat
  • Saat sebagian server offline, browser dan curl cepat beralih ke server pengganti, tetapi permintaan yang melewati proksi Cloudflare terus memakai origin yang ditentukan per IP klien sehingga bisa memunculkan error 521
  • Jika Cloudflare tidak memilih origin offline atau server dengan latensi terendah secara tepat, distribusi berbasis DNS round robin bisa menghubungkan pengguna ke server lambat tanpa memedulikan lokasi mereka

Gagasan dasar DNS round robin

  • Situs web berbasis VPS pada umumnya menambahkan satu A record di penyedia DNS untuk mengarahkan trafik ke IP tertentu
  • DNS round robin adalah metode yang menetapkan beberapa IP server pada subdomain yang sama
    • Contohnya adalah konfigurasi dengan beberapa A record pada rr-direct.hyperknot.com dan rr-cf.hyperknot.com
  • Dengan konfigurasi ini, diharapkan beban dapat dibagi ke beberapa server dan server yang offline dapat dihindari
  • Di sebagian besar penyedia DNS, ini bisa diatur tanpa load balancer terpisah sehingga menjadi pendekatan yang sederhana dan nyaris gratis
  • Fitur load balancing dari layanan seperti Cloudflare bisa menimbulkan beban biaya yang besar

Berdasarkan apa klien dapat memilih server

  • Standar yang relevan di sini adalah RFC 8305 Happy Eyeballs dan RFC 6724
  • Bagian pengurutan alamat di RFC 8305 menjelaskan bahwa bila klien yang memiliki state menyimpan catatan estimasi round-trip time (RTT) untuk jalur tiap alamat, maka ia harus menambahkan aturan pemilihan alamat tujuan yang memprioritaskan alamat dengan RTT lebih rendah
  • Penguji menafsirkan ini sebagai perilaku berikut
    • Memeriksa apakah server online atau offline
    • Mengurutkan server online berdasarkan waktu ping

Konfigurasi pengujian

  • Membuat VPS di 3 wilayah di seluruh dunia
    • Amerika Serikat
    • Eropa
    • Singapura
  • Di Cloudflare, dikonfigurasi 3 A record yang diproksikan dan 3 A record yang tidak diproksikan
  • Setiap server memberikan struktur respons yang sama menggunakan nginx
    • Semua permintaan jalur ditulis ulang ke color.png
    • /server mengembalikan /etc/hostname sebagai text/plain
  • color.png adalah file PNG 1px, dan tiap server memiliki warna berbeda
    • US: hijau
    • EU: biru
    • SG: merah
  • Hostname dibedakan sebagai test-eu, test-us, dan test-sg
  • Karena lokasi pengujian berada di Eropa, perilaku yang diharapkan adalah server EU terdekat dipilih
  • Halaman uji HTML memvisualisasikan hasil pemilihan server dengan mengisi gambar acak pada grid 10x10

Perilaku tiap klien saat semua server online

  • Chrome cenderung memilih satu lokasi yang agak acak dari beberapa pilihan, lalu tetap bertahan pada server yang sudah dipilih
    • Beberapa jam kemudian, ia akan mengevaluasi ulang pilihannya
    • Dalam pengujian, kadang ia tetap terkunci pada server Singapura yang paling lambat selama beberapa jam
    • Saat tidak memakai HTTP/2, kadang ia memilih secara acak di antara dua server dan membentuk pola
  • Firefox juga berperilaku mirip Chrome
    • Memilih lokasi acak saat awal
    • Jika browser dimulai ulang, ia bisa memilih lokasi acak yang berbeda
  • Safari selalu memilih server terdekat dengan benar
    • Meski server sempat offline lalu kembali online, setelah beberapa kali refresh ia akan kembali menemukan server EU
  • curl juga terkoreksi ke server terdekat
    • Pada eksekusi pertama mungkin belum, tetapi setelah perintah dijalankan dua kali, ia selalu berpindah ke server terdekat
    • Dalam contoh, permintaan pertama menuju test-us, lalu permintaan berikutnya berubah menjadi test-eu

Perilaku saat melewati proksi Cloudflare

  • Cloudflare memilih satu lokasi acak berdasarkan IP klien lalu terus memakai lokasi yang sama
  • Perilaku yang diamati mirip dengan client_ip_hash modulo server_num
  • Dari IP rumah, apa pun yang dilakukan, Cloudflare terhubung ke server AS
  • Dari hotspot seluler, koneksi selalu menuju server EU
  • Saat menjalankan perintah curl yang sama dari beberapa VPS, tiap VPS terhubung ke lokasi acak di seluruh dunia, tetapi selalu memakai server yang sama
    • Hasil contohnya adalah test-sg

Perbedaan saat sebagian server offline

  • Perilaku diperiksa setelah menghentikan nginx di server AS dengan service nginx stop
  • Chrome, Firefox, Safari, dan curl semuanya mendeteksi server offline lalu memilih server lain
  • Bahkan bila server dimatikan saat sedang memuat, koneksi pengganti bekerja sangat cepat, cukup untuk terkoreksi dalam waktu kurang dari 1 detik
  • Cloudflare tidak dapat mendeteksi server offline
    • Server yang sekali ditentukan untuk IP klien akan terus diakses terlepas dari status online-nya
    • Jika server tersebut offline, pengguna akan menerima error
    • Hasil curl menampilkan error code: 521

Pertanyaan dan keterbatasan terkait Cloudflare

  • Perilaku Cloudflare yang tidak dapat mendeteksi origin offline dianggap sangat mungkin merupakan bug pada jaringannya
  • Berdasarkan dokumentasi Cloudflare tentang zero downtime failover, dinilai bahwa Cloudflare seharusnya berperilaku seperti browser dan curl
  • Paling tidak, server offline seharusnya dapat dideteksi
  • Akan lebih baik lagi bila ia bisa memilih server dengan latensi terendah seperti Safari
  • Dengan perilaku saat ini, jika ada 1 server di AS dan 1 server di Selandia Baru, 50% pengguna AS bisa menerima respons dari server Selandia Baru
  • Pengguna Safari bisa menjadi lebih lambat saat memakai Cloudflare dibanding saat tidak memakainya
  • Dalam diskusi HN terkait, CEO dan CTO Cloudflare memberikan tanggapan
  • Juga ditanyakan apakah ada platform serverless yang mendukung HTTPS dan DNS round robin tanpa biaya untuk 3 VPS di seluruh dunia agar eksperimen bisa terus dijalankan

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-27
Komentar Hacker News

  • Hmm, saya sudah meminta tim DNS otoritatif menjelaskan apa yang terjadi di sini
    Kalau sudah mendapat jawaban pasti, saya akan memberi tahu HN. Sudah beberapa tahun sejak saya melihat kodenya, dan selama itu banyak orang terus mengubahnya :-)
    Dugaan saya, ini berkaitan dengan perilaku untuk mempertahankan preferensi antara IP klien dan server backend, seperti yang disebutkan penulis di blog. Pertanyaan utamanya adalah “kalau server backend mati, apakah preferensi itu harus dipatahkan?”; kalau saya tahu lebih banyak, saya akan membalas komentar saya sendiri

    • Benar-benar banyak dosa telah dilakukan atas nama preferensi sesi
    • Pembaruan: perubahan sedang digulirkan agar failover tanpa downtime juga berfungsi untuk akun gratis

  • Salah satu solusi awal untuk masalah ini adalah record DNS SRV. Mirip record MX, tetapi dimaksudkan berlaku untuk semua layanan, bukan hanya email
    Pada record MX dan SRV, klien bisa menentukan daftar server yang akan dicoba beserta prioritasnya, dan SRV juga memiliki parameter weight untuk load balancing. Namun, untuk menghindari pertarungan politis yang pada dasarnya akan memaksa semua protokol standar dicegat agar semua klien memeriksa SRV, SRV ditetapkan hanya digunakan jika standar protokol terkait secara eksplisit menyatakan penggunaan SRV. Jadi secara teknis klien HTTP tidak bisa memakai SRV. Belakangan, saat membuat HTTP/2 dan standar HTTP setelahnya, argumen yang kurang tepat dari Google dan pihak lain membuat SRV tidak berhasil dicantumkan untuk protokol HTTP baru. SRV pada dasarnya sudah mati untuk pengembangan baru, dan tampaknya hanya dipakai di sebagian standar lama
    Solusi load balancing baru tampaknya adalah record DNS HTTPS dan SVCB. Sejauh yang saya pahami, ini distandardisasi oleh orang-orang yang ingin memasukkan parameter tambahan ke DNS agar handshake TLS 1.3 bisa dimulai lebih cepat dan jumlah round-trip berkurang. Tipe record SVCB sama seperti HTTPS, tetapi dalam bentuk yang digeneralisasi seperti SRV. HTTPS dan SVCB memiliki parameter prioritas seperti SRV dan MX, tetapi tidak memiliki parameter weight milik SRV. Standarnya sudah dipublikasikan dan dukungan tampaknya sudah masuk ke beberapa browser, tetapi belum semua mengaktifkannya. Kita harus melihat apa yang benar-benar akan dilakukan browser dalam waktu dekat

    • Keunggulan besar lain dari record HTTPS adalah memungkinkan delegasi mirip CNAME yang benar di apex domain
      Ini tidak memerlukan trik CNAME flattening yang bisa menyebabkan masalah routing pada CDN yang memakai GeoDNS bersama anycast atau sebagai penggantinya. Jika Anda pernah melihat suatu platform menyarankan penggunaan subdomain www alih-alih apex domain, inilah alasannya, dan ini juga salah satu alasan Akamai mendorong standardisasi record HTTPS karena mereka memakai GeoDNS
    • Saya benar-benar berharap record bergaya SRV atau MX yang bisa digunakan untuk HTTP diadopsi dengan baik
      Karena orang-orang sering ingin meng-host situs web di apex domain, ketiadaan record semacam ini terasa sangat menyakitkan. Namun, jika tidak bisa mengandalkan DNSSEC, memakai record bergaya MX dengan aman bisa cukup rumit

  • Load balancing DNS punya kasus batas yang benar-benar berantakan. Saya pernah menangani situasi klien Go HTTP/2 memakai DNS round-robin dan muncul masalah
    Klien Go HTTP/2 terus menggunakan ulang server pertama yang bisa tersambung dan tidak melakukan resolusi DNS ulang. Akibatnya, saat server baru ditambahkan ke pool, klien bisa saja tidak menemukan server baru tersebut
    Kasus yang sangat patologis adalah ketika semua backend mati lalu satu backend pertama kembali hidup, semua klien terpaku pada server itu dan tidak berpindah. Bahkan ketika server lain sudah hidup, mereka sudah terhubung ke server pertama sehingga hampir tidak ada klien yang membuat koneksi baru
    Masalah serupa juga terjadi di grpc-go. Resolver DNS gRPC hanya melakukan resolusi ulang ketika koneksi backend terputus. Jadi klien gRPC bisa menumpuk pada satu host lalu terus bertahan di sana. Ada juga saran untuk menetapkan MAX_CONNECTION_AGE di sisi server agar klien diputus secara berkala setelah waktu tertentu, sehingga klien melakukan resolusi DNS ulang
    Saya berharap ada solusi standar yang lebih baik untuk service discovery. Pada akhirnya, tampaknya yang terbaik yang bisa dilakukan adalah mengimplementasikan load balancer per-permintaan berbasis IP virtual, lalu membuat load balancer itu melakukan health check. Namun ini pun hanya memindahkan masalah ke sistem yang mengimplementasikan IP virtual. Sepertinya asumsinya adalah sistem routing relatif lebih statis dibanding backend, dan di sanalah manfaatnya muncul
    Saya penasaran bagaimana ini dilakukan di bare metal. Saya tahu AWS/GCP dan lainnya punya load balancer internal, tetapi saya penasaran apa rahasia implementasinya. Rekomendasi artikel blog atau whitepaper terkait juga bagus

    • Saya bukan pakar DNS, tetapi bukankah seharusnya melakukan resolusi ulang saat TTL kedaluwarsa?

  • Katanya, “Apa yang terjadi kalau salah satu server offline? Anggap kita menghentikan server AS: service nginx stop”, tetapi sebaiknya jangan menguji dengan cara ini
    Klien akan melihat koneksi ditolak lalu beralih ke IP berikutnya. Namun dalam kenyataan, server bisa saja sama sekali tidak merespons, atau menerima koneksi lalu diam
    Saat itu Anda bergantung pada timeout klien, dan DNS round-robin yang dimaksudkan untuk meningkatkan keandalan tiba-tiba terlihat jauh kurang menarik

    • Benar. Anda bisa menguji dengan mematikan daya mesin fisik atau VM yang memiliki IP tersebut, atau mencabut kabelnya
      Menghentikan layanan adalah pekerjaan terencana, dan dalam kasus itu Anda bisa menanganinya dengan memperbarui DNS terlebih dahulu
    • SIG_STOP atau DROP dengan ip/nftables adalah pengujian yang jauh lebih realistis

  • “Seperti yang Anda lihat, semua klien mendeteksi ini dengan benar dan memilih server pengganti” adalah inti masalah yang berantakan. Keandalan ditentukan di sisi klien
    Misalnya, systemd-resolved dulu selalu mengembalikan alamat IP terendah, dengan alasan berperilaku setepat mungkin secara teknis. Logikanya, round-robin DNS tidak terdefinisi dengan baik, jadi selalu mengembalikan IP terendah pun tidak salah. Setelah kehebohan itu memang berubah, tetapi setahu saya Debian 11 pernah terikat pada perilaku tersebut, atau begitu untuk waktu yang lama
    Selain itu, ada banyak aplikasi yang perilaku retry-nya buruk atau bahkan tidak ada sama sekali. Cara kerjanya seperti, “Ada satu koneksi ditolak, batalkan semuanya, keluar, dan jangan pernah coba lagi.” Kalau begitu, 20–30% dari seluruh request hangus begitu saja
    Jika tidak ada pilihan lain, ini solusi yang bisa diterima. Seperti disebutkan dalam tulisan, bila Anda punya HTTP client berkualitas seperti browser yang dikonfigurasi untuk melakukan beberapa retry, round-robin DNS cukup baik untuk menemukan load balancer sungguhan yang memiliki health check dan semacamnya, dan bisa memberikan tingkat keberhasilan 100%
    Namun round-robin DNS bukan load balancer, dan load balancer memang lebih baik

    • Sebaliknya, jika Anda mengendalikan klien dan bisa menjamin perilakunya, load balancing DNS sangat efektif
      Di tempat saya dulu bekerja, ada server DNS internal dengan ratusan juta record dan TTL 60 detik, yang digunakan untuk sistem routing internal khusus guna mengarahkan koneksi masuk pelanggan ke resource yang tepat di dalam jaringan. Dalam praktiknya, itu sangat bagus. Perubahan routing sesederhana update DDNS, dan dengan NOTIFY perubahan didorong ke semua server turunan sehingga rata-rata latensi hingga propagasi penuh kurang dari 60 detik. Itu membuat pembuatan alat yang lebih kompleks menjadi mudah, termasuk panel kontrol yang bisa mengeluarkan apa pun dari layanan dengan sekali klik, dari satu server hingga seluruh data center
      Sistem itu jelas punya sisi-sisi kasar, tetapi untuk sistem semacam itu, ia cepat, mudah diinspeksi, dan relatif hampir tahan banting
    • Artinya Anda menyerahkan keandalan ke tangan klien atau resolver DNS caching acak di belakangnya
      Failover juga sama. Jika satu region down, apakah Anda ingin traffic tersebar merata ke region lain, atau terkonsentrasi ke region tetangga terdekat berikutnya? Jika perilaku itu penting, Anda harus mempertahankan kendali atas manajemen traffic, bukan menyerahkannya kepada orang lain
    • Saya juga sulit setuju dengan pernyataan “jika tidak ada pilihan lain, ini solusi yang bisa diterima”
      Saat ini, jauh sebelum mencapai kondisi “tidak ada pilihan lain” itu, ada banyak solusi lain yang seharusnya dipilih

  • Sedikit mempermasalahkan dengan hati-hati soal deteksi offline otomatis DNS dalam ungkapan “membagi beban ke beberapa server, dan secara otomatis mendeteksi server mana yang offline lalu memilih server yang online”: round-robin DNS dalam kondisi dasar hanya layak dipakai untuk load balancing
    Kecuali Anda memasukkan logika pintar ke klien, tidak ada apa pun yang otomatis terjadi dalam hal deteksi status ketersediaan. Bagian pembuka tulisan memang menyinggung hal ini sampai batas tertentu, tetapi saya harus membacanya beberapa kali untuk memahami maksudnya. Agar adil, mungkin itu masalah pemahaman saya. Setelah membaca sisa tulisannya, ternyata semuanya membahas logika pintar tersebut
    Jika record server 1/N yang dipilih browser tidak tersedia, tidak ada pemulihan otomatis atau retry di level protokol
    Tambahan “hal menarik terkait”: jangan lupa perilaku DNS TTL [1] dan .equals() [2] di Java
    [1] https://stackoverflow.com/questions/1256556/how-to-make-java...
    [2] https://news.ycombinator.com/item?id=21765788 (5 tahun lalu, 168 komentar)

    • Route53 menangani ini dengan menghapus server dari respons DNS jika server tidak sehat, dan menyajikan semua respons dengan TTL yang sangat rendah
      Memang ada klien yang mengabaikan TTL, tetapi itu cukup jarang
    • Sedikit promosi: ini proyek bebas dan open source yang menyediakan failover untuk round-robin DNS, dan didukung oleh NLnet: https://codeberg.org/FedericoCeratto/rrdnsd

  • Jika server down, alamat IP yang tersebar dan di-cache di seluruh dunia tetap ada, dan tidak ada cara untuk mencegah orang mengakses alamat tersebut
    https://www.cloudflare.com/learning/dns/glossary/round-robin...

    • Melewati lapisan perantara yang tidak perlu patut dipertimbangkan
      Load balancing juga punya biaya, dan ada juga masalah load balancer yang merusak koneksi secara halus atau terang-terangan. Pada salah satu penyedia, ketersediaan load balancer bahkan pernah lebih buruk daripada host kami
      Jika Anda mengendalikan klien, memanggil platform DNS API untuk mendapatkan daftar IP lalu mengacak dan merotasikannya dengan tepat juga masuk akal. Lebih baik lagi jika beberapa IP yang dialokasikan secara stabil bisa dimasukkan ke binary klien sebagai antisipasi saat DNS rusak. Namun DNS biasanya tidak rusak, dan berguna untuk perubahan operasional tanpa harus menerapkan konfigurasi atau binary baru setiap kali memperbarui cluster
      Jika kliennya adalah browser, perilaku bawaannya cukup baik. Biasanya IP dipakai berurutan sehingga bisa menjadi masalah [1], tetapi selain itu perilaku retry-nya bagus. Jika koneksi ditolak, browser langsung mencoba IP lain; jika terjadi timeout, setidaknya ia mencoba beberapa IP lain. Ini tidak ideal, jadi untuk browser saya akan memakai load balancer, dan jika memungkinkan setidaknya untuk initial page load saya akan melakukannya. Untuk WebSocket dan sejenisnya, DNS round robin dan logika klien JS yang cukup pintar juga bisa digunakan. Meski begitu, memakai DNS round robin untuk seluruh situs tetap mungkin
      Jika kliennya bukan browser dan juga tidak Anda kendalikan, satu-satunya yang bisa dilakukan adalah berharap beruntung
      Saya 100% mengakui bahwa kadang-kadang kita harus berasumsi ada orang yang membuat resolver caching DNS dan menafsirkan field TTL sebagai hari, bukan detik. Klien di balik resolver semacam itu akan bermasalah saat DNS diperbarui. Namun jika load balancer berada di balik nama DNS dan suatu saat alamatnya harus diubah, masalah itu tetap akan muncul, dan saat itu Anda juga belum punya pengalaman menghadapinya
      [1] Salah satu RFC menyarankan agar OS API mengurutkan respons berdasarkan prefix match. Ini bisa masuk akal jika prefix IP bersifat hierarkis dan merupakan proxy untuk memilih server dengan jarak jaringan terdekat. Namun di dunia nyata, /24 yang berdekatan secara numerik sering kali tidak berdekatan di jaringan. Jika alamat server tersebar luas, Anda mungkin melihat trafik dari sebagian IP klien terkonsentrasi ke IP server yang mirip secara numerik
    • Klien yang diuji dalam artikel berperilaku dengan benar dan memilih salah satu server yang dapat dijangkau
      Tentu saja akan selalu ada orang yang salah mengonfigurasi DNS lokal atau memakai klien yang buruk. Untuk orang-orang dengan konfigurasi yang rusak, Anda harus menerima gangguan atau menetapkan ulang IP ke server lain di data center yang sama
    • Cara standar saat ini adalah memakai TTL yang relatif rendah, dan DNS server melakukan health check terhadap anggota pool

  • Halo. Saya CTO Cloudflare. Kami telah menerapkan perubahan ke semua akun gratis Cloudflare agar perilakunya sama seperti akun berbayar
    Masalah yang disebutkan di sini sudah diperbaiki, dan Zero Downtime Failover seharusnya berfungsi untuk semua jenis akun. Bisakah Anda mengujinya lagi?
    Terima kasih sudah menuliskannya. Kami senang bisa mengubah perilaku ini untuk semua orang

    • Saya sudah mengujinya lagi dan berfungsi dengan sangat baik
      Saya juga akan memperbarui artikelnya sesuai dengan itu. Terima kasih sudah menerapkannya juga untuk akun gratis; ini hasil yang bagus

  • Versi remix gelap dari ini adalah fast flux hosting, metode yang dipakai banyak penyedia bulletproof hosting
    https://unit42.paloaltonetworks.com/fast-flux-101/

  • Mungkin perlu disebutkan bahwa failover tanpa downtime adalah fitur Pro ke atas
    Saya ingat dulu, ketika dokumentasi perlindungan origin server masih dipisahkan berdasarkan tingkat paket, hal itu juga didokumentasikan demikian. Jadi perilaku atau retry-nya bisa terlihat berbeda