Cara terbaik untuk memuat saldo di beberapa server file statis bahkan untuk distribusi bandwidth?

Pertama, saya akan menjelaskan situasi saya kepada Anda. Saya menjalankan situs web yang cukup populer sebagai proyek sampingan, jadi saya tidak dapat benar-benar menginvestasikan banyak uang ke dalamnya. Saat ini saya hanya memiliki satu server dengan HAProxy di depan mengirimkan permintaan normal ke Apache, dan semua permintaan file statis ke Lighttpd. Ini berfungsi dengan sangat baik karena semua permintaan php dan posting ditangani oleh Apache, sementara semua gambar dikirim ke Lighttpd yang lebih cepat (situs ini sebagian besar gambar, jadi ini sangat penting). Alangkah baiknya untuk tidak perlu membuat sub-domain untuk menyajikan gambar, karena URL pendek juga sangat penting, jadi alasan saya untuk menggunakan HAProxy.

Saya telah menemukan penyedia hosting yang menawarkan bandwidth unmetered cukup murah yang telah saya gunakan, masalahnya muncul ketika saya mulai mendorong bandwidth sebanyak yang dapat ditangani oleh kartu jaringan 100mbs, sehingga membutuhkan server kedua.

Saya telah banyak memikirkan pilihan saya, jadi saya akan menjelaskan masing-masing kepada Anda. Mudah-mudahan Anda bisa memberikan wawasan tentang mana yang merupakan pilihan terbaik bagi saya, atau mungkin ada opsi lain di luar sana yang belum saya pikirkan.

Persyaratan:

• Bahkan distribusi bandwidth adalah suatu keharusan. Saya memiliki server yang cukup kuat, jadi meningkatkan bukan pilihan. Saya perlu mengurangi untuk mendapatkan lebih banyak bandwidth.

• URL pendek. Saya benar-benar tidak ingin menyiapkan subdomain, seperti img.example.com, untuk menyajikan gambar saya. example.com/image.jpg adalah bagaimana sekarang, dan bagaimana saya benar-benar ingin tetap. Tetapi jika tidak ada cara lain, maka saya mengerti.

• Server clostest yang menangani permintaan akan sangat bagus, tetapi bukan keharusan. Sesuatu yang perlu diingat.

HAProxy untuk memuat keseimbangan:

• Ini akan sangat mudah dilakukan karena saya sudah menggunakan HAProxy. Namun, saya pikir masalah muncul ketika mendistribusikan bandwidth. Saya mungkin salah dalam hal ini, tetapi bukankah HAProxy mengirim permintaan ke server tempat server memprosesnya dan kemudian mengirimkannya kembali melalui HAProxy ke klien? Dengan demikian, semua lalu lintas keluar melalui load balancer yang menyebabkannya menggunakan bandwidth sebanyak semua server digabungkan.

DNS Round Robin:

• Ini mungkin pilihan terbaik saya. Cukup gandakan situs web di beberapa server dan lakukan apa yang saya lakukan sekarang. The downside adalah bahwa jika satu server turun, klien masih dikirim ke sana. Saya juga perlu meniru situs di beberapa server. Saya agak berharap bahwa saya dapat memiliki satu server utama yang menangani semuanya kecuali file statis, dan kemudian memiliki beberapa server file statis. Saya juga membaca bahwa ini semacam 'penyeimbangan muatan orang miskin', dan akan menyenangkan jika memiliki sesuatu yang sedikit lebih canggih.

Pengembalian Server Langsung:

• Tampaknya sangat rumit, tetapi mungkin merupakan pilihan yang baik. Apakah saya masih dapat mengirim URL tertentu ke server tertentu? Seperti sekarang dengan HAProxy, setiap URL yang berakhir dengan ekstensi file yang tepat dikirim ke Lighttpd, sedangkan ekstensi lainnya dikirim ke Apache. Jadi saya akan membutuhkan sesuatu yang serupa. Seperti, semua permintaan php ditangani oleh server yang sama yang menjalankan perangkat lunak penyeimbang, sementara semua permintaan jpg dikirim ke beberapa server.

Idealnya, jika HAProxy mendukung Direct Server Return, maka masalah saya akan terpecahkan. Saya juga tidak ingin menggunakan CDN, karena harganya sangat mahal, dan ini hanyalah proyek sampingan.

Apakah Anda mengerti masalah saya? Beri tahu saya jika saya tidak menjelaskan sesuatu dengan benar atau jika Anda memerlukan info lebih lanjut.

Gambarlah siklus permintaan / respons Anda untuk aplikasi dan mengisolir kemacetan. Anda benar bahwa proxy tunggal yang mendistribusikan beban ke banyak server aplikasi akan memerlukan bandwidth agregat dari semua server aplikasi. Solusi klasiknya adalah RR DNS. Google, Yahoo dan Amazon semuanya menggunakan teknik ini dengan TTL pendek. Saya melakukan investigasi beberapa waktu lalu dan mendokumentasikan temuan saya .

Solusi lain adalah menggunakan solusi penyeimbangan beban perusahaan celana mewah menggunakan pengalamatan IP virtual untuk menyeimbangkan permintaan di antara beberapa server aplikasi dengan alamat IP nyata. Saya telah bekerja dengan produk Netscaler dan Stonesoft. Keduanya berkinerja baik tetapi memiliki kekhasan yang mengerikan dan cukup kompleks.

Beberapa jawaban:

• Ya, semua lalu lintas lewat melalui HAProxy, karena berfungsi sebagai proksi tingkat HTTP. Ini akan sama bahkan jika HAProxy diinstal pada server terpisah yang memuat saldo beberapa server back end. Jadi, jika penyedia hosting Anda hanya memasok port jaringan 100MBit, dan Anda sudah mendorong 100MBit, maka Anda memiliki masalah.
• Mengenai domain, hal yang optimal adalah menayangkan gambar dari domain yang berbeda dari aplikasi web Anda - bukan subdomain, yang berbeda, sehingga cookie tidak dikirim bersama berdasarkan permintaan gambar. Lihat karya asli Steve Souders , atau implementasinya di sini di Stack Overflow . Jika URL pendek sangat penting bagi Anda, mungkin hal terbaik adalah memindahkan webapp dari URL utama, yaitu memindahkan aplikasi manajemen file ke login.sitename.com?

Apakah Anda memerlukan otentikasi pada permintaan gambar? Jika tidak, bagaimana dengan menggunakan sesuatu seperti Amazon S3? Ini scalable besar-besaran, dan biaya transfer data cukup murah. Dalam hal ini saya akan menggunakan sesuatu seperti i.sitename.com sebagai DNS CNAME untuk nama host bucket Amazon S3, lihat Amazon dokumen . AFAIK Anda tidak dapat memiliki nama domain root (sitename.com) sebagai CNAME, jadi Anda harus menggunakan subdomain seperti i.sitename.com untuk ini.

Anda juga dapat memotong gambar Anda di beberapa server. Yaitu Anda membuat struktur DNS seperti login.sitename.com dan a.sitename.com; b.sitename.com; c.sitename.com dan lain-lain. Sebuah." dan B." server dll hanya berisi sistem file dengan gambar, dan server HTTP ringan (Anda sudah menggunakan Lighttpd, jadi terus gunakan itu. Untuk proyek masa depan, saya akan mengusulkan untuk melihat nginx sebagai pengganti yang lebih baik.) Ketika pengguna mengunggah sebuah gambar, Anda membuat hash dari pengidentifikasi unik, mungkin nama pengguna, mungkin nama file, atau kombinasi beberapa pengidentifikasi . Dari hash ini, Anda menentukan server tempat menyimpan gambar.

Sunting Saya seharusnya melihat bahwa hashing sudah dibahas. Pada dasarnya yang saya usulkan di sini adalah hanya menggunakan hashing pada nama host juga, untuk menyebarkan lalu lintas jaringan secara merata pada banyak host.

Saya tidak tahu seberapa murahnya Anda - tetapi ketika Anda mendorong lalu lintas jaringan 100MBit, maka "murah dan bagus" dengan cepat berubah menjadi ilusi. Mungkin Anda harus melihat mendapatkan model bisnis yang baik terlebih dahulu, sesuatu yang memberikan pendapatan berulang, dan kemudian menerapkan teknologi yang sesuai sesudahnya?

Saya menganggap HAProxy ada di server yang sama dengan aplikasi Anda yang lain? Anda dapat memecah HAProxy ke sistem lain untuk menjalankan permintaan dan membuatnya mengirim permintaan normal ke satu server, dan permintaan gambar ke server lain. Masalahnya adalah semua permintaan masih masuk ke satu kotak, dan jika Anda menjenuhkan bandwidth maka itu mungkin tidak banyak membantu Anda.

Anda mengatakan URL pendek itu penting. Mengapa? Apakah benar-benar masalah untuk mengalihkan gambar dari "example.com" ke "i.example.com"? Anda dapat mengatur "i" ke IP sendiri di server sendiri dengan Lighttpd dan memotong HAProxy sepenuhnya, menyelesaikan masalah throughput Anda. Anda juga akan mendapatkan manfaat dari browser web yang memungkinkan lebih banyak permintaan terbuka sekaligus karena akan menganggapnya sebagai nama domain yang berbeda dan dapat membuka lebih banyak koneksi bersamaan. Jika server "i" tunggal jenuh, Anda bisa menggunakan DNS round-robin untuk menambahkan yang lain. Semoga saat itu Anda menghasilkan cukup pendapatan untuk mengimplementasikan solusi yang lebih baik.

Apakah penyedia hosting Anda menawarkan layanan penyeimbangan beban? Saya pikir ini solusi terbaik.

Cara lain untuk melakukannya, tetapi perlu diuji, adalah menulis ulang (dalam terang atau apache) permintaan. Misalnya: example.com/file.html tetap di apache dan example.com/image.jpg redirect ke i.example.com/image.jpg. Semua permintaan akan dikelola melalui apache tetapi respons (bandwidth upstream) akan menuju ke server lighttpd. Domain ini transparan bagi pengguna. Masih Anda perlu menguji apakah apache dapat menangani semua permintaan atau mungkin membiarkan lighttpd melakukan pekerjaan ini.

Anda benar semua data melewati HAProxy sehingga Anda tidak dapat (sejauh yang saya tahu) melakukan server langsung kembali dengannya.

MEMPERBARUI

Mencari di dokumentasi HAproxy saya menemukan parameter "redir". Saya tidak tahu apakah itu bisa berfungsi seperti apache menulis ulang tetapi ini bisa bermanfaat. Dokumentasi mengatakan:

Penggunaan utama terdiri dari peningkatan bandwidth untuk server statis dengan membuat klien terhubung secara langsung ke mereka.

Mungkin berhasil untuk kasus Anda.

Saya berasumsi bahwa dengan set gambar yang cukup besar Anda tidak menyimpan gambar berdasarkan nama file aslinya karena Anda akan mengalami konflik nama dengan cukup cepat.

Banyak aplikasi yang menangani masalah jenis ini menggunakan hash file dan struktur direktori berdasarkan hash itu. Struktur direktori terlihat seperti berikut ini di mana jalur direktori adalah dua karakter pertama dari hash kemudian direktori level 2 adalah dua karakter berikutnya dalam hash.

/image root/AA/AA/images  
/image root/AA/AB/images

Manfaatnya di sini adalah hash menjaga distribusi file tetap merata dan memberikan Anda namespace yang mudah dibagi ke beberapa server. Pada dasarnya Anda melayani bagian dari ruang hash dari server yang berbeda dan saat Anda menskalakan Anda dapat membagi ini lebih lanjut sesuai kebutuhan.

The downside adalah bahwa hash tidak sempurna dan mungkin ada tabrakan. Saya tidak yakin bagaimana ini ditangani. Sehingga mungkin perlu sedikit riset di pihak Anda. Saya membayangkan bahwa aturan penulisan ulang di proxy harus dapat mengambil hash katakanlah A3A8BBC83261.jpg dan menulis ulangnya ke http://img3.domain.com/A3/A8/BBC83261.jpg . Anda mungkin tidak menganggap itu url pendek.

Dalam posting Anda Anda menyebutkan bahwa Anda merasa round robbin DNS mungkin menjadi pilihan terbaik Anda tetapi Anda khawatir tentang satu server gagal ...

Jika itu masalahnya, lihat Simple Failover dari JH Software. Saya sudah menggunakannya di masa lalu dan itu bekerja dengan sangat baik.

http://www.simplefailover.com

Pada dasarnya ia memonitor server Anda dan ketika melihat salah satu turun dengan cepat menulis ulang DNS untuk menarik server mati dari rotasi.

Berikut cuplikan dari situs web mereka:

Simple Failover terus memantau server Anda untuk mencari tahu mana yang naik dan yang turun, dan kemudian secara dinamis memperbarui catatan DNS Anda sesuai sehingga nama domain Anda selalu menunjuk ke server fungsional.

Ia bekerja dengan server web (HTTP), server email (SMTP, IMAP, POP3), server FTP, dan hampir semua jenis server berbasis TCP / IP lainnya.

Seperti yang disebutkan sebelumnya, saya pernah menggunakannya untuk situs web dan server email. Itu dilakukan dengan cukup baik. Dalam banyak kasus Failover cukup cepat (menebak 2-5 menit) dan saya katakan hampir semua orang gagal dalam waktu kurang dari 15 menit.

Belum tentu SEMPURNA ... tapi pasti cepat dan mudah.

CATATAN: Ini adalah produk windows. Saya tidak yakin apakah mereka memiliki versi linux atau tidak, tetapi Anda bisa gagal di server mana pun yang Anda suka karena berbasiskan DNS.

Dalam kasus kami, kami hanya melemparkannya pada mesin XP, menyuruh mesin untuk reboot sekali malam, dan itu berjalan baik selama bertahun-tahun.