Tugasnya adalah mengimplementasikan solusi toleran kesalahan untuk dua server web dan, jika mungkin, untuk menerapkan load balancing antara server web, karena kadang-kadang satu database tidak dapat mengatasi semua permintaan. Itu tidak mungkin untuk membeli peralatan khusus, sehubungan dengan mana skema berikut diciptakan. Mungkin idenya tidak asli, tetapi di internet saya tidak menemukan yang seperti itu. Topologi kami adalah sebagai berikut:
Ada Router Cisco yang membawa server web ke Internet. Dua server web pada Centos 7 dengan nginx. Alamat IP dari server web pertama dan kedua masing-masing adalah 192.168.20.176/24 dan 192.168.20.177/24. Untuk mengimplementasikan rencana tersebut, server web perlu menetapkan alamat ip sekunder yang sama. Ini bisa berupa alamat ip pribadi yang tidak digunakan di jaringan Anda. Saya memilih 192.168.120.175 dan mendaftarkannya dengan alamat ip sekunder dari antarmuka eth0 utama dari server web. Pada Centos, ini dilakukan dengan membuat file eth0: 0 di direktori / etc / sysconfig / network-scripts /. Isi file:
TYPE="Ethernet" DEVICE=eth0:0 BOOTPROTO="static" IPADDR=192.168.120.175 NETMASK=255.255.255.255 ONBOOT="yes"
Penting untuk dicatat bahwa mask 255.255.255.255 digunakan dan ini menghindari konflik ip, karena server web tidak akan menggunakannya untuk menghasilkan lalu lintas. Jadi untuk berbicara, kita akan memiliki antarmuka Loopback di server web.
Setelah itu, router dapat mengimplementasikan load balancing menggunakan routing statis. Teknologi ini diimplementasikan menggunakan IP Cef pada router Cisco. Tautkan di
sini . Vendor lain mungkin memiliki nuansa tertentu.
Di Cisco, distribusi utas dapat dalam dua cara:
- Per-Tujuan (default). Kami membutuhkan opsi ini. Semua paket dari satu aliran akan dikirim ke salah satu dari dua server. Prinsip operasi adalah bahwa hash dihitung oleh sumber dan alamat ip tujuan, dan tergantung pada hash ini, baik rute pertama (server) atau yang kedua dipilih. Selanjutnya, kami akan sedikit mengubah perilaku ini.
- Per-Paket. Opsi ini tidak cocok untuk kita, karena penyeimbangan akan terjadi pada paket. Secara kasar, paket pertama di rute pertama, paket kedua di kedua.
Kami meresepkan dua rute dengan bantuan perintah:
ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.176 ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.177
Dengan demikian, kedua rute akan dipasang di tabel routing dan distribusi beban akan dilakukan di sepanjang rute tersebut:
Kami juga memeriksa apakah metode penyeimbangan dipilih dengan benar:
Sumber alamat IP akan berubah, dan IP Tujuan akan selalu dibiarkan sendiri. Ini dapat mempengaruhi keseimbangan keseragaman, mengingat NAT. Untuk optimasi, Anda dapat mempertimbangkan port sumber, yang akan berbeda secara acak, tergantung pada sesi klien. Untuk melakukan ini, gunakan perintah berikut:
ip cef load-sharing algorithm include-ports source
Anda juga perlu mengonfigurasi NAT statis untuk mengarahkan permintaan web ke alamat 192.168.120.175:
ip nat inside source static tcp 192.168.120.175 80 interface GigabitEthernet0/1 80
Apa yang kita dapatkan Permintaan dari pengguna dari Internet akan masuk ke router kami, yang akan mendistribusikannya di antara server kami dengan aliran, tergantung pada port sumber di TCP. Ketika Anda membuka sesi baru, klien dapat masuk ke server baru.
Apa yang terjadi jika salah satu server lumpuh? Rute yang mengarah ke server ini akan dihapus dari tabel routing. Untuk mengoptimalkan proses ini, Anda dapat menggunakan IP SLA. Monitor status server dengan melakukan ping setiap 10 detik:
ip sla 10 icmp-echo 192.168.20.176 frequency 10 ip sla schedule 10 life forever start-time now ip sla 20 icmp-echo 192.168.20.177 frequency 10 ip sla schedule 20 life forever start-time now
Selanjutnya, tambahkan pemantauan ke rute yang sesuai:
ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.176 track 10 ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.177 track 20
IP SLA pada router Cisco juga memungkinkan pemantauan dengan permintaan HTTP GET, yang akan membantu menentukan crash server web tidak hanya oleh ketidakhadirannya dalam jaringan, tetapi juga ketika layanan web sedang down.
Jadi, untuk membangun skema semacam itu tidak memerlukan peralatan tambahan dan perangkat lunak apa pun untuk server web. Yang Anda butuhkan adalah router dengan kemampuan untuk menyeimbangkan lalu lintas.