On Tue, Jun 24, 2003 at 08:15:38PM -0400, fade2blac wrote: > wah kebetulan ga ada tcpdump di pc yang skrg dipakai. Mungkin: > > tcpdump -nni ethx arp
bener. yang ini dapatnya memang cuman arp broadcast. tapi setelah saya pikir-pikir bener juga, habis mau dapat apa lagi? :-) setelah saya cek di tiap-tiap interface, problemnya pasti bukan karena ini. tapi memang sulit dilacak berhubung kalau dipikir-pikir saya tidak memahami benar peta/topologi network yang ada disekitar LVS. > pake direct routing ya? ya .. kalau tidak pakai TUN ya DR he..he.. > Kan tugas redirectnya sudah ditangani sama load balancer, jadi ngapain > real server ikut-ikutan redirect. Kecuali kalau memang ada specific > purpose. redirect dengan iptables/ipchains ini ide awalnya dari Horms, untuk menghindari problem ARP. tapi kalau pakai iptables, sayangnya harus mengaktifkan ip conntrack, menghabiskan resources. but, it works. dengan redirect paket, VIP tidak perlu diassign secara eksplisit di real server. cukup dibuat rule yang meredirect paket yang ditujukan ke VIP sebagai paket lokal ala transparent proxy. > Kenapa nggak implementasi LVS/NAT? tidak ada IP yang sama. performance kurang bagus, setidaknya ini dibuktikan dengan testlvs. untuk itu digunakan LVS/DR. yang jelas, jangan berharap bisa menjalankan service yang bersangkutan dengan 1 NIC he..he.. > implementasikan model apa? Model tunnel kalau nggak salah harus punya > alias IP sebanyak real servernya. Dan ini bisa jadi SPOF. by design, LVS router itu sudah merupakan SPOF. kecuali pakai setup HA, misal dengan heartbeat atau pakai keepalived (vrrp). > > patch untuk LVS-nya saja. saya ingin tahu, kenapa real service > > yang sudah dapat weight zero, masih saja ada paket (SYN) yang > > masuk, dan stuck. 'service' sendiri jelas tidak jalan, jadi > > kalau toh masih dapat giliran, ini kok tidak dapat ECONREFUSED? > > bug di implementasi LVS? > > Mungkin. Kalau weight-nya zero, kenapa masih dipasang sebagai real > server? sayangnya problem hanya terjadi pada 1 segmen saja (setidaknya dari yang complain). saya menduga ada problem lainnya, tidak hanya berkaitan dengan LVS per se. tapi seperti yang saya bilang di atas, saya perlu mengenal topologi network secara keseluruhan untuk melacak problemnya. cuman lagi capek mikir :-))) dengan keepalived, 'dead' real server otomatis diberi bobot 0 (berdasar konfigurasi yang saya set). bukan sengaja memasang real server dengan weight 0. prinsipnya, keepalived diperintahkan kirim tcp check (kirim syn packet) ke real server port x. tidak mendapat jawaban selama 3 detik, real server dianggap mati -> dibobot 0. kalau dari tcpdump, begitu real server meresponse, keepalived otomatis membalas dengan RST, sehingga tidak ada koneksi 'real' (test ini tidak membebani real server). seringkali, yang sudah didesign, direncanakan, dipahami tidak berjalan seperti yang diharapkan :-) saya bayangkan yang >=1 detik itu (re-check tiap detik). ada puluhan client mengakses service dan stuck. jadi repot. atau sebaiknya jangan set inhibit_on_failure (parameter keepalived) ya, tapi langsung dilepas dari daftar real server aktif, dengan efek samping, koneksi yang sekarang established lah yang stuck. sama juga bohong ... memang antisipasi terhadap kasus 'failure' ini di mana-mana selalu problematik. cuman orang ngomongnya saja yang enteng. apalagi yang jualan ;p Salam, P.Y. Adi Prasaja -- Right or wrong my list. Unsubscribe option is currently unavailable. Indeed, it's available upon request .. but: cepek dulu donk!
