Memuat penyeimbangan Apache dengan anggaran?

Saya mencoba memahami konsep load balancing untuk memastikan ketersediaan dan redundansi untuk membuat pengguna senang ketika ada masalah, daripada load balancing demi menawarkan kecepatan terik kepada jutaan pengguna.

Kami memiliki anggaran terbatas dan berusaha untuk tetap berpegang pada hal-hal di mana ada banyak pengetahuan yang tersedia, jadi menjalankan Apache di Ubuntu VPS sepertinya adalah strategi sampai beberapa mesin pencari terkenal mendapatkan kami ( termasuk ironi hari Sabtu, harap dicatat ).

Setidaknya bagi saya, itu adalah hutan lengkap solusi berbeda yang tersedia. Apache sendiri mod_proxy & HAproxy adalah dua yang kami temukan dengan pencarian google cepat, tetapi tidak memiliki pengalaman load balancing, saya tidak tahu apa yang cocok untuk situasi kami, atau apa yang akan kami jaga saat memilih solusi untuk menyelesaikan masalah ketersediaan.

Apa pilihan terbaik untuk kita? Apa yang harus kita lakukan untuk mendapatkan ketersediaan tinggi sementara tetap berada di dalam anggaran kita?

Solusi yang saya gunakan, dan dapat dengan mudah diimplementasikan dengan VPS, adalah sebagai berikut:

• DNS round-robin'ed (sp?) Ke 6 alamat IP yang valid berbeda.
• Saya memiliki 3 load balancers dengan konfigurasi yang identik dan menggunakan corosync / pacemaker untuk mendistribusikan 6 ip adresses secara merata (sehingga setiap mesin mendapat 2 adresses).
• Setiap penyeimbang beban memiliki konfigurasi nginx + pernis . Nginx berurusan dengan menerima koneksi dan melakukan penulisan ulang dan beberapa penyajian statis, dan meneruskannya kembali ke Varnish yang melakukan load balancing dan caching.

Lengkungan ini memiliki keuntungan sebagai berikut, menurut pendapat saya yang bias:

1. corosync / pacemaker akan mendistribusikan ulang alamat ip jika salah satu dari LB gagal.
2. nginx dapat digunakan untuk melayani SSL, jenis file tertentu langsung dari sistem file atau NFS tanpa menggunakan cache (video besar, audio atau file besar).
3. Varnish adalah penyeimbang beban yang sangat baik yang menopang bobot, memeriksa kesehatan backend, dan melakukan pekerjaan luar biasa sebagai proxy terbalik.
4. Dalam hal dibutuhkan lebih banyak LB untuk menangani lalu lintas, cukup tambahkan lebih banyak mesin ke cluster dan alamat IP akan diseimbangkan kembali antara semua mesin. Anda bahkan dapat melakukannya secara otomatis (menambah dan menghapus penyeimbang muatan). Itu sebabnya saya menggunakan 6 ips untuk 3 mesin, untuk memberikan ruang bagi pertumbuhan.

Dalam kasus Anda, memiliki VPS yang terpisah secara fisik adalah ide yang bagus, tetapi membuat berbagi ip lebih sulit. Tujuannya adalah memiliki sistem yang tahan kesalahan, redundan, dan beberapa konfigurasi untuk penyeimbangan beban / HA dan mengacaukannya menambah satu titik kegagalan (seperti penyeimbang beban tunggal untuk menerima semua lalu lintas).

Saya juga tahu Anda bertanya tentang apache, tetapi saat itu kami memiliki alat khusus yang lebih cocok untuk pekerjaan itu (seperti nginx dan vernis). Biarkan apache untuk menjalankan aplikasi di backend dan sajikan dengan menggunakan alat lain (bukan berarti apache tidak dapat melakukan penyeimbangan muatan yang baik atau membalikkan proksi, itu hanya masalah pembongkaran berbagai bagian pekerjaan ke lebih banyak layanan sehingga setiap bagian dapat melakukannya dengan baik ini berbagi).

HAproxy adalah solusi yang baik. Konfigurasi ini cukup lurus ke depan.

Anda akan membutuhkan instance VPS lain untuk duduk di depan setidaknya 2 VPS lainnya. Jadi untuk load balancing / fail over, Anda membutuhkan minimal 3 VPS

Beberapa hal yang perlu dipikirkan juga adalah:

1. Pengakhiran SSL. Jika Anda menggunakan HTTPS: // koneksi itu harus berakhir di load balancer, di belakang load balancer itu harus melewati semua lalu lintas melalui koneksi yang tidak terenkripsi.

2. Penyimpanan file. Jika pengguna mengunggah gambar ke mana ia pergi? Apakah itu hanya duduk di satu mesin? Anda perlu berbagi file secara instan di antara mesin - Anda dapat menggunakan layanan S3 Amazon untuk menyimpan semua file statis Anda, atau Anda dapat memiliki VPS lain yang akan bertindak sebagai server file, tetapi saya akan merekomendasikan S3 karena itu berlebihan dan murah murah.

3. info sesi. setiap mesin dalam konfigurasi penyeimbang beban Anda harus dapat mengakses info sesi pengguna, karena Anda tidak pernah tahu mesin apa yang akan mereka tekan.

4. db - apakah Anda memiliki server db yang terpisah? jika Anda hanya memiliki satu mesin sekarang, bagaimana Anda akan memastikan mesin baru Anda akan memiliki akses ke server db - dan jika server VPS db terpisah, seberapa mubazirnya. Itu tidak selalu masuk akal untuk memiliki ujung depan Ketersediaan Tinggi web dan satu titik kegagalan dengan satu server db, sekarang Anda perlu mempertimbangkan replikasi db dan promosi budak juga.

Jadi saya sudah di posisi Anda, itulah masalah dengan situs web yang melakukan beberapa ratus hit sehari untuk operasi nyata. Menjadi kompleks dengan cepat. Harapan yang memberi Anda beberapa makanan untuk dipikirkan :)

Pilihan saya adalah untuk Linux Virtual Server sebagai load balancer. Hal ini membuat direktur LVS titik kegagalan tunggal serta hambatan, tetapi

1. Hambatan itu, menurut pengalaman saya, bukanlah masalah; langkah pengalihan LVS adalah layer-3, dan sangat (secara komputasi) murah.
2. Satu-satunya titik kegagalan harus ditangani dengan memiliki direktur kedua, dengan dua dikendalikan oleh Linux HA .

Biaya dapat ditekan dengan meminta direktur pertama berada di mesin yang sama dengan simpul LVS pertama, dan direktur kedua di mesin yang sama dengan simpul LVS kedua. Node ketiga dan selanjutnya adalah node murni, tanpa implikasi LVS atau HA.

Ini juga membuat Anda bebas untuk menjalankan perangkat lunak server web apa pun yang Anda suka, karena pengalihan dilakukan di bawah lapisan aplikasi.

Bagaimana dengan rantai ini?

round robin dns> haproxy di kedua mesin> nginx untuk memisahkan file statis> apache

Mungkin juga menggunakan ucarp atau detak jantung untuk memastikan haproxy selalu menjawab. Stunnel akan duduk di depan haproxy jika Anda memerlukan SSL juga

Anda mungkin ingin mempertimbangkan untuk menggunakan perangkat lunak pengelompokan yang tepat. RedHat's (atau CentOS) Cluster Suite , atau Oracle's ClusterWare . Ini dapat digunakan untuk mengatur cluster aktif-pasif, dan dapat digunakan untuk me-restart layanan, dan gagal di antara node ketika ada masalah serius. Ini pada dasarnya adalah apa yang Anda cari.

Semua solusi kluster ini sudah termasuk dalam lisensi OS masing-masing, jadi Anda mungkin tidak masalah biaya. Mereka memang memerlukan beberapa cara penyimpanan bersama - baik mount NFS, atau disk fisik yang diakses oleh kedua node dengan sistem file berkerumun. Contoh yang terakhir adalah disk SAN dengan beberapa akses host diizinkan, diformat dengan OCFS2 atau GFS . Saya percaya Anda dapat menggunakan disk bersama VMWare untuk ini.

Perangkat lunak cluster digunakan untuk mendefinisikan 'layanan' yang berjalan pada node sepanjang waktu, atau hanya ketika node itu 'aktif'. Node berkomunikasi melalui detak jantung, dan juga memantau layanan tersebut. Mereka dapat me-restart mereka jika mereka melihat kegagalan, dan reboot jika mereka tidak dapat diperbaiki.

Anda pada dasarnya akan mengkonfigurasi satu alamat IP 'dibagikan' yang mengarahkan lalu lintas ke. Kemudian apache, dan layanan lain yang diperlukan, dapat didefinisikan juga, dan hanya berjalan di server aktif. Disk bersama akan digunakan untuk semua konten web Anda, semua file yang diunggah, dan direktori konfigurasi apache Anda. (dengan httpd.conf, dll)

Dalam pengalaman saya, ini bekerja dengan sangat baik.

• Tidak perlu untuk round robin DNS, atau penyeimbang beban satu-titik-kegagalan lainnya - semuanya menyentuh satu IP / FQDN.
• File yang diunggah pengguna masuk ke penyimpanan bersama itu, dan karenanya tidak peduli jika mesin Anda gagal.
• Pengembang mengunggah konten ke IP / FQDN tunggal itu dengan nol pelatihan tambahan, dan selalu terbarui jika gagal.
• Administrator dapat mengambil mesin offline, menambal heck keluar dari itu, reboot, dll. Kemudian gagal simpul aktif. Melakukan peningkatan, butuh waktu henti yang minimal.
• Node yang sekarang kedaluwarsa dapat disimpan tanpa ditunggu untuk sementara waktu, membuat proses gagal-kembali sama mudahnya. (Lebih cepat dari snapshot VMWare)
• Perubahan pada konfigurasi Apache dibagikan, sehingga tidak ada yang aneh terjadi selama failover, karena admin lupa untuk membuat perubahan pada kotak offline.

--Christopher Karel

Penyeimbangan muatan yang optimal bisa sangat mahal dan rumit. Penyeimbangan beban dasar harus memastikan bahwa setiap server melakukan servis kira-kira jumlah hit yang sama kapan saja.

Metode load-balancing yang paling sederhana adalah menyediakan beberapa catatan A dalam DNS. Secara default alamat IP akan dikonfigurasi dalam metode round robin. Ini akan menghasilkan pengguna yang didistribusikan secara merata di seluruh server. Ini berfungsi baik untuk situs stateless. Diperlukan metode yang sedikit lebih rumit ketika Anda memiliki situs stateful.

Untuk menangani persyaratan stateful, Anda dapat menggunakan arahan ulang. Berikan setiap server web alamat alternatif seperti www1, www2, www3, dll. Arahkan ulang koneksi www awal ke alamat alternatif host. Anda mungkin berakhir dengan masalah bookmark dengan cara ini, tetapi mereka harus tersebar secara merata di server.

Bergantian, menggunakan jalur yang berbeda untuk menunjukkan server mana yang menangani sesi stateful akan memungkinkan sesi proxy yang telah berpindah host ke server asli. Ini mungkin menjadi masalah ketika sesi untuk server yang gagal tiba di server yang telah mengambil alih dari server yang gagal. Namun, kecuali perangkat lunak pengelompokan negara akan hilang pula. Karena caching peramban, Anda mungkin tidak mengalami banyak sesi mengubah server.

Kegagalan dapat ditangani dengan mengkonfigurasi server untuk mengambil alih alamat IP dari server yang gagal. Ini akan meminimalkan waktu henti jika server gagal. Tanpa perangkat lunak pengelompokan, sesi stateful akan hilang jika server gagal.

Tanpa failover, pengguna akan mengalami penundaan hingga browser mereka gagal ke alamat IP berikutnya.

Menggunakan layanan Restful daripada sesi stateful harus menghilangkan masalah pengelompokan di front-end. Masalah pengelompokan di sisi penyimpanan masih akan berlaku.

Bahkan dengan penyeimbang beban di depan server, Anda mungkin akan memiliki DNS round-robin di depannya. Ini akan memastikan semua penyeimbang beban Anda digunakan. Mereka akan menambahkan layer lain ke desain Anda, dengan kompleksitas tambahan dan titik kegagalan lainnya. Namun, mereka dapat menyediakan beberapa fitur keamanan.

Solusi terbaik akan tergantung pada persyaratan yang relevan.

Menerapkan server gambar untuk menyajikan konten seperti gambar, file CSS, dan konten statis lainnya dapat memudahkan pemuatan pada server aplikasi.

Saya biasanya menggunakan sepasang mesin OpenBSD yang identik:

• Gunakan RelayD untuk menyeimbangkan beban, pemantauan server web, dan penanganan server web yang gagal
• Gunakan CARP untuk ketersediaan tinggi penyeimbang beban sendiri.

OpenBSD ringan, stabil, dan cukup aman - Sempurna untuk layanan jaringan.

• http://www.openbsd.org - Situs utama
• http://www.openbsd.org/faq/pf/carp.html - Dokumentasi karper
• https://calomel.org/relayd.html - Kumpulan info howto yang layak di RelayD

Untuk memulai, saya merekomendasikan pengaturan layer3. Ini menghindari pengaturan firewall komplikasi (PF). Berikut ini adalah contoh /etc/relayd.conf file yang menunjukkan pengaturan penyeimbang beban relai sederhana dengan pemantauan webserers backend:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Pernahkah Anda memberi ec2 dengan cloudfoundry atau mungkin Elastic beanstalk atau hanya AWS biasa yang menggeser pemikiran. Saya telah menggunakan itu dan timbangannya cukup baik dan menjadi elastis dapat ditingkatkan / turun tanpa campur tangan manusia.

Mengingat bahwa Anda mengatakan Anda tidak memiliki pengalaman dengan load balancing, saya akan menyarankan opsi ini karena mereka membutuhkan otak minimal "penggorengan" untuk bangkit dan berjalan.

Mungkin lebih baik menggunakan waktu Anda.