perbedaan load-balancing antara DNS dan IP - penerusan vs redirect


9

Saya telah menemukan sebuah situasi yang tidak dapat saya mengerti. Kami memiliki firewall Fortigate yang telah kami aktifkan untuk melakukan load-balancing di dua server web Apache back-end. Nama DNS kemudian dipetakan ke IP virtual pada Load Balancer.

Seperti yang diharapkan, ketika Anda menjelajah ke nama / URL DNS (mis. Www.something.com), Load Balancer menyajikan halaman dari salah satu server web Apache back-end. URL di browser tetap www.something.com . Dari apa yang saya mengerti, Load Balancer dalam hal ini hanyalah meneruskan paket-paket antara browser dan Apache sambil tetap berada di jalur.

Namun, jika saya meramban ke alamat IP yang dipetakan oleh DNS, maka Load Balancer mengembalikan HTTP 302 Found, dengan header Lokasi diatur ke URL DNS dari salah satu Apache. URL di browser berubah menjadi DNS server back-end.

Mengapa Load Balancer mengarahkan ulang ketika ditanyai melalui IP, tetapi meneruskan jalur dengan benar saat ditanyai melalui nama DNS.

Jawaban:


10

Saya belum pernah menggunakan Fortigate FW untuk load balancing, jadi saya akan menjawab beberapa pertanyaan secara lebih umum.

Pertama, tentang masalah Anda, penyeimbang beban melakukan persis seperti yang seharusnya dilakukan dan saya pikir server Anda mungkin tidak dikonfigurasi dengan benar untuk menanggapi permintaan pada alamat IP mereka. Jika Anda menguji ini di belakang load balancing, Anda dapat mengatur nama domain dalam file host klien lokal, di belakang firewall dengan server dan mengaksesnya baik dengan nama domain dan IP internal. Anda mungkin akan mendapatkan hasil yang sama seperti yang Anda lihat sekarang.

Dugaan saya adalah Anda mengaktifkan hosting virtual (untuk mendukung beberapa domain pada satu server) dan "default" tidak melayani halaman yang sama dengan domain Anda. Anda mendapatkan halaman web kembali dari server dalam kedua kasus. Jika Anda memerlukan bantuan untuk mengonfigurasi server web Anda, Anda mungkin ingin mencoba di ServerFault .

Kedua, untuk sedikit lebih detail. Load balancer biasanya beroperasi pada L7 untuk setidaknya HTTP dan HTTPS cluster. Ini berarti bahwa mereka tidak hanya melihat alamat IP dan meneruskannya, juga tidak "mengarahkan" halaman tersebut.

Ketika mereka menerima permintaan, mereka benar-benar mem-parsing permintaan dan meneruskannya ke server setelah memproses permintaan. Ada banyak hal yang dapat mereka lakukan pada saat ini, seperti menulis ulang header di kedua arah, berpotensi menambahkan cookie (untuk kegigihan) ke dalam data yang akan kembali ke klien, mengakhiri sesi SSL, mencocokkan berdasarkan pada URL, dll.

Saya sarankan Anda meluangkan waktu sepenuhnya membaca dokumen vendor untuk mendapatkan pemahaman yang lebih baik tentang cara kerja load balancing (dengan Fortigate Anda dapat membaca keduanya dan Coyote Point - perusahaan penyeimbang beban lain yang diperoleh Fortigate). Memahami apa yang dilakukannya akan membantu Anda dalam kasus-kasus seperti ini dan akan memungkinkan Anda membuka kunci kemampuan yang tidak Anda sadari ada.


Masalahnya adalah konfigurasi pada server web Apache back-end. Nama DNS baru perlu ditambahkan sebagai Alias.
Yusuf

3

Setelah membaca penyeimbangan beban berbasis host HTTP di Fortigate Load Balancing doc, saya bisa melihat bagaimana Anda dapat memiliki konfigurasi penyeimbangan beban yang tidak lazim yang dapat menghasilkan apa yang Anda gambarkan. Namun, tanpa bagian dari konfigurasi Anda, kami tidak dapat memastikan apakah ini yang terjadi pada Anda.

Fortigate FortiOS memungkinkan Server Virtual dibuat yang terkait dengan Server Nyata yang masing-masing memiliki konfigurasi header host yang berbeda . Jika ada permintaan yang cocok dengan VIP Server Virtual Anda, permintaan yang seimbang hanya akan masuk ke Server Nyata yang cocok dengan itu host header. Bagian terpenting yang menjelaskan dengan baik gejala Anda, adalah bahwa salah satu Server Nyata dapat menghilangkan header host sehingga cocok dengan header host apa pun .

Server nyata tanpa header host mungkin telah dikonfigurasi sebagai semacam "catch-all" yang mendarat di situs yang melakukan pengalihan.

Dengan menggunakan contoh di bawah ini, hanya rservers ke-1 dan ke-2 yang menangani lalu lintas yang cocok dengan nama DNS pilihan Anda melalui header host, tetapi rserver ke-3 mengambil apa pun yang cocok dengan semua header host lain yang mencakup DNS VIP itu sendiri dan mengirimkan ke situs yang dapat melakukan pengalihan .

config firewall vip
 sunting "http-host-ldb"
  atur jenis server-load-balance
  atur extip 192.0.2.1
  atur extintf "lan"
  atur jenis server http
  atur ldb-metode http-host
  atur extport 80
  config realservers
    edit 1
      atur http-host "www.example.com"
      atur ip 192.168.2.1
      atur port 80
      lanjut
    edit 2
      atur http-host "www.example.com"
      atur ip 192.168.2.2
      atur port 80
      lanjut
    edit 3
      atur ip 192.168.2.3
      atur port 80
      lanjut
    akhir
 akhir

Saya kira firewall load-balancing bisa melakukan redirect itu sendiri, tetapi kita tidak bisa mengatakan dengan info terbatas yang disediakan.


Dalam konfigurasi ini, sedang diatur ke pencocokan berbasis nama. Dan itu masalahnya. Jika Anda pergi ke VIP dengan alamat, itu tidak akan tahu apa yang harus dilakukan dengannya. (Aturan NAT normal akan berlaku)
Ricky Beam

Alasan utama saya tidak percaya ini menjadi jawabannya adalah bahwa tidak ada penyeimbang FW / beban yang saya tahu akan mengembalikan 302 dengan lokasi yang disetel ke nama host / domain sumber daya internal (setidaknya tanpa secara khusus mengonfigurasinya untuk melakukan jadi, yang kedengarannya bukan kasus berdasarkan pertanyaan).
YPelajari

@ RickyBeam, hanya orang pertama yang mendaftar yang melakukan pencocokan nama host. Server terakhir akan cocok dengan alamat VIP sebagai tuan rumah.
generalnetworkerror

@YLearn, Saya setuju bahwa ini akan aneh; Saya mengatakan rserver, bukan LB, akan melakukan 302 dan akan dikonfigurasikan untuk melakukannya. Saya tahu tidak ada LB baik yang akan melakukan itu.
generalnetworkerror
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.