Squid atau Cache HTTP Lain dengan SSD Cache Store?

Saya sedang mempertimbangkan pengaturan cache squid (atau mungkin pernis) pada sistem dengan drive SSD.

Manfaat yang jelas adalah bahwa sistem ini memiliki kecepatan BACA yang besar dan saya berharap rasio hit saya cukup tinggi.

Mari kita asumsikan saya dapat memasukkan 7 SSD ke konfigurasi RAID. (ada beberapa kasus yang akan membuat saya berkemas lebih banyak)

Pertanyaan implementasi:

• Haruskah saya menggunakan RAID0? (Saya berharap drive pada akhirnya gagal, jadi ini sepertinya berbahaya.)

• Haruskah saya menggunakan RAID10? (Ini membagi dua jejak disk saya, yang mahal.)

• Haruskah saya menggunakan RAID5? (SSD diketahui memiliki kinerja tulis dan batas tulis "buruk", dan semua penulisan paritas tambahan dapat memperlambat ini secara signifikan.)

• Haruskah saya memperlakukan setiap disk sebagai squid datastore sendiri? (seberapa baik squid menangani banyak penyimpanan data? Dan apa yang terjadi jika salah satu gagal?)

• Haruskah saya mengabaikan datastore dan hanya membuat SSD ke partisi SWAP besar dan membiarkan VM linux melakukan itu? (tampaknya ceroboh)

Setiap saran dari orang yang menggunakan SSD di lingkungan produksi akan sangat dihargai. (esp jika Anda menggunakannya untuk cache HTTP)

Kami telah menggunakan pernis pada drive SSD selama 9 bulan terakhir, itu telah bekerja dengan sangat baik bagi kami. Kami sebelumnya menggunakan cache hanya memori squid dengan lapisan karper. Itu berhasil, tetapi fragmentasi memori adalah masalah nyata yang membutuhkan restart sering. Squid 2.x juga hanya akan menggunakan satu inti yang membuatnya agak tidak efisien pada perangkat keras saat ini.

Untuk situs kami, yang sangat ramah cache, kami melihat sekitar 10% penggunaan CPU pada mesin 8 core yang melayani 100Mbit / s traffic. Dalam pengujian kami, kami kehabisan bandwidth sebelum mencapai batas cpu dengan 2 port 1Gb.

Saya punya beberapa saran untuk menjalankan pernis dengan ssd cache.

• Performa menulis acak sangat penting. Kami mencoba beberapa vendor untuk drive SSD sebelum memilih intel x-25m. Kami telah melihat beberapa posting sesedikit .1MB / s untuk penulisan acak 4k, kami mendapatkan menulis acak 24MB / s 4k dengan x-25m.

• Raid0. Cache di 2.0 tidak persisten, jadi tidak perlu khawatir tentang redundansi. Ini memang membuat restart sakit, tetapi itu jarang terjadi. Anda dapat melakukan hal-hal seperti memuat konfigurasi dan membersihkan objek tanpa memulai ulang.

• mode mmap. Tembolok pernis dapat mmap'd ke file atau menggunakan ruang swap. Menggunakan swap tidak berfungsi dengan baik bagi kami, ia cenderung menggunakan lebih banyak bandwidth i / o untuk melayani jumlah lalu lintas yang sama. Ada 4 sektor readahead dalam kode swapin linux, kami menulis patch untuk menghapus ini tetapi belum mencobanya dalam produksi.

• Penjadwal tenggat waktu. Dengan 2.6.28+ ini ssd aware dan berkinerja baik. Kami mencoba noop tetapi menemukan bahwa tenggat waktu lebih adil karena bandwidth i / o menjadi terbatas.

• Nonaktifkan baca sebelumnya. Karena tidak ada penundaan rotasi, tidak ada gunanya membaca data tambahan hanya karena Anda mungkin membutuhkannya. I / o bandwidth sangat berharga untuk hal-hal ini.

• Jalankan 2.6.28+. mmap banyak ruang di linux memberikan manajer memori latihan yang baik, tetapi patch split lru banyak membantu. penggunaan cpu kswapd turun banyak ketika kami memperbarui.

Kami telah memposting file vcl kami serta beberapa alat yang kami gunakan dengan pernis pada teks tautan . Vcl juga menyertakan peretasan rapi yang mengimplementasikan server geoiplookup yang sangat cepat berdasarkan pada basis data maxmind.

Saya tidak menggunakan SSD sebagai cache HTTP, tapi saya bisa melakukan pengamatan ini:

Tidak semua SSD sama, jadi Anda harus sangat berhati-hati dalam memilih yang layak. FusionIO membuat SSD yang didukung PCIe yang benar-benar berkinerja tinggi (dengan kapasitas yang relatif rendah), tetapi mahal. Intel X25-E SLC SSD berkinerja sangat baik, dan lebih terjangkau, tetapi kapasitasnya masih rendah. Lakukan riset Anda! Saya pasti dapat merekomendasikan varian X25-E SLC, karena saya menggunakan ini dalam sistem produksi.

Ada SSDS lain di luar sana yang dapat memberi Anda kecepatan baca / tulis berurutan yang besar, tetapi yang penting untuk sesuatu seperti cache adalah IO acak, dan banyak SSD akan memberikan kinerja acak yang kira-kira sama dengan disk berputar. Karena menulis efek penguatan pada SSD, disk pemintalan akan sering berkinerja lebih baik. Banyak SSD memiliki pengontrol kualitas yang buruk (misalnya, pengontrol JMicron yang lebih tua), yang dapat mengalami penurunan kinerja secara signifikan dalam beberapa situasi. Anandtech dan situs lain melakukan perbandingan yang baik dengan alat seperti iometer, periksa di sana.

Dan, tentu saja, SSD kecil. Intel X25-E, yang akan saya katakan adalah SSD SATA terbaik yang pernah saya lihat, hanya datang dalam varian 32 dan 64 GB.

Untuk level RAID, catatan kinerja RAID standar masih berlaku. Penulisan ke RAID 5 secara Bauran melibatkan membaca blok data yang akan Anda modifikasi, membaca blok paritas, memperbarui paritas, menulis blok data, dan menulis paritas, sehingga masih akan memberikan kinerja yang lebih buruk daripada RAID lainnya level, bahkan dengan SSD. Namun, dengan drive seperti X25-E yang memiliki kinerja IO acak yang begitu tinggi, ini mungkin kurang penting - karena akan tetap mengungguli IO acak pada disk pemintalan untuk array ukuran yang sama.

Dari apa yang saya lihat, bandwidth pengontrol RAID jenuh terlalu cepat untuk mendapatkan manfaat maksimal dari 7 disk RAID, setidaknya sejauh menyangkut kinerja berurutan. Anda tidak bisa mendapatkan lebih dari sekitar 800MB / s dari model pengontrol SATA saat ini (3ware, areca dll). Memiliki array yang lebih kecil, melintasi beberapa kontroler (mis., Beberapa RAID1 daripada RAID10 tunggal) akan meningkatkan ini, meskipun kinerja individual dari setiap array akan menderita.

Mengenai cache HTTP, saya pikir Anda akan lebih baik disajikan dengan array yang baik dari disk berputar, dan banyak ram. Objek yang sering diakses akan tetap berada di cache memori - baik di cache internal squid, atau di cache fs OS Anda. Cukup memberi mesin lebih banyak ram dapat secara signifikan mengurangi pemuatan disk karena ini. Jika Anda menjalankan squid cache yang besar, Anda mungkin membutuhkan banyak ruang disk, dan SSD berkinerja tinggi hanya datang dengan kapasitas yang relatif rendah.

Saya tidak terlalu terbiasa dengan drive SSD, tetapi saya dapat berbicara tentang jenis arsitektur yang saya gunakan yang dapat membantu menyelesaikan beberapa masalah Anda.

Saudara kandung

Dalam kasus saya, saya membangun empat server dengan masing-masing 16GB RAM. Saya menetapkan 9GB sebagai cache memori untuk digunakan Squid. Saya mengkonfigurasi mereka sebagai satu set saudara sehingga permintaan ke satu server akan meminta yang lain sebelum mencari data. Secara keseluruhan saya memiliki cache memori sebesar 36GB. Saya tidak akan memiliki lebih dari empat saudara kandung karena komunikasi di antara mereka mulai macet.

VIP

Saya mengkonfigurasi VIP untuk empat server untuk diajak bicara klien. Ini memecahkan apa yang terjadi ketika satu server turun.

Anak-anak

Saya mengatur aplikasi web saya untuk meminta server Squid lokal berjalan pada 127.0.0.1. Kemudian konfigurasikan induk dari instance Squid ini menjadi VIP. Hal ini memungkinkan terjadinya failover yang sangat cepat jika seluruh VIP turun. Jika orang tua tidak merespons, anak langsung menanyakan layanan. Ini juga berguna jika Anda menggunakan server Squid tunggal dan tidak memiliki VIP. Tentu saja jika instance Squid lokal pada server web Anda mati semuanya berhenti.

Cumi itu sendiri

Saya belum benar-benar melihat 3.0, tetapi 2.x masih single threaded. Pada titik tertentu Anda akan kehabisan buffer CPU atau TCP. Saya akan menyebar cache ke 2-3 kotak kurang jika memungkinkan. Anda juga mungkin ingin membuat rencana untuk mempartisi peternakan Squid Anda di masa depan jika Anda melihat sistemnya berkembang.

Bagaimanapun, semoga berhasil dengan SSD Anda. Saya tertarik mendengar bagaimana hasilnya karena saya mungkin akan menempuh rute itu di masa depan.

Mengapa Anda bahkan mempertimbangkan serangan 10 atau 5. Anda ingin kinerja di sini. Anda tidak peduli jika drive hanya turun, karena itu hanya cache.

Cukup gunakan raid 0 atau pisahkan. Saya pikir terpisah akan lebih baik, karena kegagalan drive tidak akan menghapus seluruh cache Anda.

Dokumentasi Squid merekomendasikan untuk tidak menggunakan RAID tetapi untuk mengatur direktori cache tambahan pada disk tambahan.