Bagaimana kami membangun penyimpanan S3 DataLine. Eksperimen, pengujian, dan sedikit tentang kuda nil

Halo lagi, Alexey Pristavko berhubungan, dan ini adalah bagian kedua dari cerita saya tentang penyimpanan objek S3 DataLine berdasarkan Cloudian HyperStore.

Hari ini saya akan berbicara secara rinci tentang bagaimana penyimpanan S3 kami diatur dan kesulitan apa yang kami temui dalam proses pembuatannya. Pastikan untuk menyentuh topik "besi" dan menganalisis peralatan tempat kami akhirnya tinggal.

Ayo pergi!

Jika selama membaca Anda memiliki keinginan untuk berkenalan dengan arsitektur aplikasi dari solusi Cloudian, Anda akan menemukan analisis terperinci di artikel sebelumnya . Di sana kami membahas secara rinci perangkat internal Cloudian, toleransi kesalahan dan logika SDS bawaan.

Skema akhir peralatan fisik

Karena nanti kita akan berbicara tentang "siksaan pilihan" kita, saya akan segera memberikan daftar besi terakhir yang telah kita terima. Penafian kecil: pilihan peralatan jaringan sebagian besar karena kehadirannya di gudang kami (yang sangat padat).

Jadi, pada tingkat penyimpanan fisik, kami memiliki peralatan berikut:

Nama	Fungsi	Konfigurasi	Jumlah
Lenovo System x3650 M5 Server	Simpul kerja	1x Xeon E5-2630v4 2.2GHz, 4x 16GB DDR4, 14x10TB 7.2K 6Gbps SATA 3.5 ", 2x 480GB SSD, Intel x520 Dual Port 10GbE SFP +, 2x750W HS PSU	4
Server HP ProLiant DL360 G9	Memuat simpul penyeimbang	2 E5-2620 v3, RAM 128G, 2 600GB SSD, 4 SAS HDD, Intel x520 Dual Port 10GbE SFP +	2
Cisco C4500 Switch	Gerbang perbatasan	Catalyst WS-C4500X-16SFP +	2
Switch Cisco C3750	Port extender	Catalyst WS-C3750X-24T dengan C3KX-NM-10G	2
Cisco C2960 Switch	kontrol pesawat	Catalyst WS-C2960 + 48PST-L	1

Untuk pemahaman yang lebih baik tentang arsitektur, kita akan melihat semua elemen pada gilirannya dan berbicara tentang fitur dan tugas mereka.

Mari kita mulai dengan server. Server Lenovo memiliki konfigurasi khusus yang diimplementasikan bersama dan sepenuhnya sesuai dengan rekomendasi dan spesifikasi Cloudian. Misalnya, mereka menggunakan pengontrol dengan akses disk langsung. Karena dalam kasus kami, RAID diatur pada tingkat perangkat lunak aplikasi, mode ini meningkatkan keandalan dan mempercepat subsistem disk. Tepatnya server yang sama dapat dibeli sebagai Peralatan Cloudian bersama dengan semua lisensi.

Load balancing server dengan Nginx for CentOS menjamin pemerataan distribusi pada node kerja dan abstrak pengguna dari organisasi traffic internal. Dan sebagai bonus yang menyenangkan - jika perlu, Anda dapat mengatur cache pada mereka.

Cisco 4500X sixteen 10GB SFP + pair berfungsi sebagai inti dan batas jaringan penyimpanan kami yang kecil namun bangga. Tentu saja, besi agak kuno, tetapi tidak kalah dengan keandalan "baru", ia memiliki redundansi internal, dan fungsinya memenuhi semua persyaratan kami. C3750 memainkan peran sebagai pabrik-extender, tidak perlu mendorong transceiver 1G ke slot 10G. Dan untuk beralih sepenuhnya ke tautan 10GB juga tidak masuk akal. Seperti yang ditunjukkan oleh tes, kami mengalami prosesor dan disk sebelumnya.

Diagram di bawah ini menggambarkan secara cukup rinci organisasi fisik yang saya jelaskan:

1. Skema organisasi penyimpanan fisik

Mari kita pergi melalui skema. Seperti yang Anda lihat, toleransi kesalahan pada level fisik diwujudkan dengan menduplikasi dan menghubungkan setiap perangkat dengan setidaknya dua tautan optik, satu untuk setiap perangkat berpasangan. Ini memberi kami jaminan menjaga konektivitas fisik di sirkuit selama kecelakaan perangkat jaringan apa pun atau dua perangkat dari pasangan yang berbeda secara bersamaan.

Kami pergi di bawah skema. Kedua pasangan Cisco (4500/4500, 3750/3750) digabungkan menjadi satu perangkat logis menggunakan tumpukan dan VSS. Tumpukan dirakit dengan dua kabel tumpukan, VSS melalui tiga tautan optik 10G. Ini memungkinkan Anda untuk memastikan bahwa kedua perangkat di setiap pasangan berinteraksi secara keseluruhan. Pengelompokan seperti ini memungkinkan kami untuk bekerja dalam kerangka kerja satu segmen L2 transparan melalui kedua perangkat berpasangan dan untuk membuat agregasi tautan umum menggunakan LACP, karena teknologi ini secara asli didukung oleh server OS dan Cisco IOS. Dari sisi server, sepertinya ia bekerja dengan satu saklar, bukan dua, dan di atas aplikasi terdapat saluran agregat kapasitas ganda.

Semua peralihan peralatan jaringan antara dirinya dan ke saluran yang masuk dilakukan dengan menggunakan tautan optik 10G, peralatan server terhubung menggunakan kabel 10G Twinax Cisco dan tembaga 1G.

BGP digunakan untuk toleransi kesalahan pada saluran yang masuk, dan Round Robin DNS digunakan untuk menyeimbangkan antara alamat IP eksternal. Alamat eksternal sendiri diparkir di server penyeimbang beban dan, jika perlu, bermigrasi di antara node menggunakan bundel Pacemaker / Corosync.

Pemantauan dan kontrol melalui IPMI dilakukan melalui tautan internal langsung. Semua antarmuka manajemen (baik server dan Cisco) terhubung melalui sakelar kontrol yang terpisah. Mereka, pada gilirannya, termasuk dalam jaringan kontrol pusat data. Ini menjamin kami tidak mungkin kehilangan komunikasi dengan peralatan selama bekerja atau sebagai akibat dari kecelakaan pada jaringan eksternal. Untuk kasus yang paling ekstrem, ada petugas dengan KVM.

Jaringan logis

Untuk memahami bagaimana jaringan logis S3 penyimpanan DataLine bekerja, mari kita beralih ke skema lain:


2. Penyimpanan diagram jaringan logis

Seperti yang Anda lihat, logika jaringan terdiri dari beberapa segmen.

Jaringan eksternal (Q) dengan kapasitas total 20G terhubung langsung ke Provider Edge. Ini diikuti oleh Cisco 4500 dan balancers.

Blok logis berikutnya (X) adalah VLAN antara balancers dan node yang bekerja. Penyeimbang menggunakan koneksi yang sama seperti untuk lalu lintas masuk. Node yang bekerja terhubung melalui tumpukan 3750 dengan 4 tautan 1G (dua untuk masing-masing 3750). Semua tautan fisik dirangkai menjadi satu tautan logis menggunakan LACP juga. Jaringan ini hanya digunakan untuk memproses lalu lintas klien.

Semua koneksi dalam cluster Cloudian (Y) melewati segmen logis ketiga yang dibangun di atas 10G. Organisasi semacam itu membantu menghindari masalah pada saluran eksternal karena lalu lintas internal dan sebaliknya. Ini adalah segmen yang sangat dimuat dan penting untuk operasi cluster. Melalui data itulah metadata direplikasi, digunakan oleh prosedur penyeimbangan ulang, dll., Oleh karena itu, kami membedakan “ketidakterbatasannya” sebagai tugas terpisah.

Sedikit keindahan

Begini tampilannya:


3. Peralatan jaringan dan penyeimbang wajah penuh


4. Sama, tampilan belakang

Perhatikan pengalihan. Pada artikel sebelumnya, rekan-rekan saya menulis tentang pentingnya kabel penanda warna, tetapi tidak akan keluar dari tempat untuk menyentuh topik ini di sini.

Kami menggunakan peralihan warna tidak hanya untuk jaringan, tetapi juga untuk daya. Ini memungkinkan teknisi kami untuk bernavigasi dengan cepat di rak dan mengurangi pengaruh faktor manusia selama pergantian.


5. Node yang bekerja


6. Tampilan belakang

Dalam foto ini Anda dapat dengan jelas melihat seberapa erat server yang bekerja diisi dengan disk - praktis tidak ada slot kosong bahkan di belakang. Ngomong-ngomong, pengorganisasian kabel seperti itu ke dalam bundel kompak tidak hanya berfungsi sebagai estetika, tetapi juga menghindari tumpang tindih kipas suplai daya, menghemat besi dari panas berlebih.

Daftar putih

Dalam komentar di artikel terakhir, saya berjanji untuk berbicara lebih banyak tentang perangkat yang masuk daftar putih.

Jika karena alasan tertentu kami sepakat dengan klien untuk mengecualikan dari akun semua bekerja dengan penyimpanan dari bagian dalam pusat data atau melalui saluran langsung ke peralatannya, maka kami perlu mengatur koneksi pribadi ke penyimpanan.

Ingat, pada diagram pertama ada cabang di DIST dan Cloud? Selain saluran Internet 20Gb utama, kami menggunakan saluran agregat untuk beralih, yang kami hubungkan semua klien di tingkat pusat data. Jika klien menginginkan tautan langsung ke penyimpanan, kami dapat mengonfigurasi VLAN dari klien ke 4500X kami dengan pembangunan rute terpisah (atau tanpa itu) dan mulai L3. Setelah itu, pengikatan pada paket tarif dikonfigurasikan pada alamat klien yang sudah ada di Cloudian itu sendiri. Kemudian, untuk semua orang yang terhubung dengan paket tarif ini, penggunaan S3 dari alamat yang masuk daftar putih tidak akan dipertimbangkan.


7. Dan berikut adalah antarmuka khusus dalam Cloudian.

Sekarang kami tidak memiliki tarif seperti itu di jaringan, tetapi jika Anda benar-benar ingin, kami dapat menyediakannya.

Sejarah konstruksi

Kami secara bertahap mendekati bagian yang paling menarik dari sejarah - pembangunan fasilitas penyimpanan. Akan ada banyak foto, sebanyak tiga upaya untuk mengatur keseimbangan lalu lintas dan beberapa tips buruk. Saya berharap bahwa analisis masalah yang kami temui di jalan akan bermanfaat bagi mereka yang bersiap untuk bekerja dengan kecepatan 10Gb + di web.

Bereksperimen dengan 10G

Sebelum saya langsung menuju inti dari bagian ini, saya membiarkan diri saya membuat penafian kecil lainnya.

Menurut tradisi yang sudah mapan, sebelum membeli peralatan bantu baru, kami pergi ke gudang dan memilih komponen yang kurang lebih cocok. Ini memungkinkan Anda untuk dengan cepat melakukan tes dan memutuskan daftar belanja di masa depan. Tentu saja, sementara kita tidak mencapai hasil yang dapat diandalkan 100%, tidak ada yang dihabiskan untuk yang produktif.

Jadi kali ini. Dan jika Cisco tidak melempar kejutan, maka dengan load balancers "keserakahan" hampir menghancurkan kita.

Pengalaman pertama. Server Supermicro

Di sini kami dikecewakan oleh keinginan untuk melakukan tes cepat dengan biaya minimal. Di gudang, kami menemukan server Supermicro yang memiliki segalanya baik-baik saja kecuali kurangnya antarmuka SFP. Kami memutuskan untuk menginstal Intel 520DA2 tercinta kami pada mereka dan segera menghadapi masalah pertama: mesin adalah unit tunggal, tetapi tidak ada riser. Pada saat yang sama, untuk beberapa alasan, korps kami tidak ada dalam daftar kompatibilitas, tetapi ada banyak orang yang bangkit.

Atas saran direktur pengembangan inovatif, Misha Solovyov, kami menghubungkan semuanya dengan riser fleksibel untuk pertanian pertambangan. Hasilnya seperti "mayat":


8. Prototipe No. 1

Saya harus menggunakan pita listrik biru yang terkenal di beberapa tempat, sehingga, Tuhan melarang, melakukan sesuatu yang singkat. Ya, pertanian kolektif. Ya, malu. Tetapi "konfigurasi" semacam itu cukup dapat diterima untuk periode percobaan.


9. Tampak belakang

Apa yang muncul dari ini terlihat jelas di tangkapan layar iperf:


10. Sebenarnya ini bukan tangkapan layar :)

Metriknya sangat menarik, bukan? Jadi kami sedih. Awalnya kami memikirkan mata-mata, kami membongkar dan meluruskan segalanya.


11. Sekilas, tidak ada chip mata-mata di sini

Mereka mengingat jalan fisika: interferensi elektromagnetik, sinyal frekuensi tinggi, dll ... Tentu saja, untuk melanjutkan percobaan dengan kuantitas dan kualitas "pertanian kolektif" tidak masuk akal. Jadi kami akhirnya membongkar sistem dan mengembalikan server.

Pengalaman kedua. Citrix Netscaler MPX8005

Dalam proses mengembalikan server ke tempat itu, kami menemukan pahlawan baru: Citrix Netscaler MPX8005. Ini adalah merek besi yang luar biasa, selain itu, hampir tidak pernah digunakan. Mereka terlihat seperti ini:


12. Perosotan di rak tidak sesuai panjangnya, tetapi kami visioner memutuskan untuk menundanya sampai nanti

Peralatan ditempatkan di rak, diaktifkan dan dikonfigurasi. Ini adalah potongan besi "dewasa" yang sangat bagus, 2 slot SFP untuk masing-masing 10GB, HA, algoritme canggih, bahkan ada L7. Benar, hingga 5 gigabit di bawah lisensi, tetapi kami masih menggunakan L3, tetapi tidak ada batasan seperti itu.

Jari juling, tes. Tidak ada kecepatan. Pada antarmuka - kesalahan solid tentang transceiver yang tidak cocok, kecepatan sekitar 5 gigabit, tetesan konstan. Mereka ingat anak tangga yang fleksibel, sedih lagi. Bahkan di sana, kecepatannya lebih tinggi, dan lebih sedikit kesalahan. Kami mulai mengerti:

show channel LA/1 1)  Interface LA/1 (802.3ad Link Aggregate) #10  flags=0x4100c020 <ENABLED, UP, AGGREGATE, UP, HAMON, HEARTBEAT, 802.1q>  MTU=9000, native vlan=1, MAC=XXX, uptime 0h03m23s  Requested: media NONE, speed AUTO, duplex NONE, fctl NONE,        throughput 160000  Link Redundancy Throughput 80000  Actual: throughput 20000  LLDP Mode: NONE  RX: Pkts(9388) Bytes(557582) Errs(0) Drops(1225) Stalls(0)  TX: Pkts(10514) Bytes(574232) Errs(0) Drops(0) Stalls(0)  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)  bandwidthHigh: 160000 Mbits/sec, bandwidthNormal: 160000 Mbits/sec.  LA mode: AUTO > show interface 10/1 1)  Interface 10/1 (10G Ethernet, unsupported fiber SFP+, 10 Gbit) #1  flags=0x400c020 <ENABLED, UP, BOUND to LA/1, UP, autoneg, 802.1q>  LACP <Active, Long timeout, key 1, priority 32768>  MTU=9000, MAC=XXX, uptime 0h05m44s  Requested: media AUTO, speed AUTO, duplex AUTO, fctl OFF,        throughput 0  Actual: media FIBER, speed 10000, duplex FULL, fctl OFF, throughput 10000  LLDP Mode: TRANSCEIVER,    LR Priority: 1024  RX: Pkts(8921) Bytes(517626) Errs(0) Drops(585) Stalls(0)  TX: Pkts(9884) Bytes(545408) Errs(0) Drops(3) Stalls(0)  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)  Bandwidth thresholds are not set. > show interface 10/2 1)  Interface 10/2 (10G Ethernet, unsupported fiber SFP+, 10 Gbit) #0  flags=0x400c020 <ENABLED, UP, BOUND to LA/1, UP, autoneg, 802.1q>  LACP <Active, Long timeout, key 1, priority 32768>  MTU=9000, MAC=XXX, uptime 0h05m58s  Requested: media AUTO, speed AUTO, duplex AUTO, fctl OFF,        throughput 0  Actual: media FIBER, speed 10000, duplex FULL, fctl OFF, throughput 10000  LLDP Mode: TRANSCEIVER,    LR Priority: 1024  RX: Pkts(8944) Bytes(530975) Errs(0) Drops(911) Stalls(0)  TX: Pkts(10819) Bytes(785347) Errs(0) Drops(3) Stalls(0)  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)  Bandwidth thresholds are not set. 

Kami menggunakan transceiver asli Cisco, yang secara teori, tidak ada masalah yang muncul. Mereka bahkan memeriksa optik dan, untuk berjaga-jaga, mengubah transceiver - gambar yang sama. Mobil kami tidak pergi, dan hanya itu! Kami melihat lebih dekat.

Transceiver Cisco "Cantik":

 ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe000-0xe01f mem 0xf7800000-0xf781ffff,0xf7840000-0xf7843fff irq 17 at device 0.1 on pci1 ix1: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8 SFP+/SFP, vendor CISCO-AVAGO , part number XXX , 10G 0x10 1G 0x00 CT 0x00 *** Unsupported SFP+/SFP type! 

Transceiver tidak terdeteksi secara normal, tidak didukung!

Saya harus menemukan "kerabat" yang paling banyak:


13. Transceiver paling asli di barat liar

 ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe020-0xe03f mem 0xf7820000-0xf783ffff,0xf7844000-0xf7847fff irq 16 at device 0.0 on pci1 platform: Manufacturer Citrix Inc. platform: NSMPX-8000-10G 4*CPU+6*E1K+2*IX+1*E1K+4*CVM 1620 675320 (28), manufactured at 8/10/2015 platform: serial 4NP602H7H0 platform: sysid 675320 - NSMPX-8000-10G 4*CPU+6*E1K+2*IX+1*E1K+4*CVM 1620 ix0: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8 SFP+/SFP, vendor CITRIX           , part number XXX   , 10G 0x10 1G 0x01 CT 0x00 ix0: [ITHREAD] 10/2: Ethernet address: 00:e0:ed:45:39:f8 ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe000-0xe01f mem 0xf7800000-0xf781ffff,0xf7840000-0xf7843fff irq 17 at device 0.1 on pci1 ix1: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8 SFP+/SFP, vendor CITRIX           , part number XXX  , 10G 0x10 1G 0x01 CT 0x00 

Transceiver ini ditentukan tanpa masalah, tetapi ini tidak menyelamatkan situasi. Firmware yang diperbarui - hal yang sama. Dukungan Citrix memutuskan untuk diam diam (tidak, bukan karena silsilah transceiver).

Kami mengambil napas dalam-dalam dan mengubur spesifikasi perangkat keras. Ternyata jawabannya selama ini ada di depan mata kita: kecepatan bus ixgbe = 5.0Gbps dan lebar jalur PCIe = 8. Ini adalah masalah dengan kartu. Dia sendiri tidak memiliki kecepatan PCIe. Citrix kami memiliki kinerja maksimum dari slot PCI-e untuk kartu dengan transceiver 5.0Gbps, yang ia teriakkan kepada kami selama ini. Seperti halnya Citrix di MPX8015 (perangkat kerasnya persis sama!) Mereka ingin membagikan 15 gigabit, itu tidak jelas. Tapi kami mengerti mengapa penyeimbang "keren" seperti itu selama ini berada di gudang. Mereka tidak dapat bekerja dengan benar dengan tautan 10G pada prinsipnya.

Pengalaman terakhir. Kami menggunakan besi yang tepat dan membuatnya indah

Di sini, kesabaran kami berakhir dengan keyakinan kami pada kemanusiaan, dan kami harus menggunakan teknologi "cadangan" untuk mendapatkan perangkat keras normal dalam bentuk HP ProLiant DL360 G9 dari foto di atas. Mereka tidak mulai mengatur kejutan untuk kami, mereka mengunduh 10G dan tidak mengeluh. :)

Uji beban

Karena kami tidak menerima pendekatan hujak-hujak-dan-produksi, dan kami tahu dari pengalaman bahwa sistem yang tidak diuji setelah perakitan dengan jaminan hampir 100% tidak dapat dioperasikan, kami memutuskan untuk melakukan pengujian beban. Selain itu, dengan bantuannya Anda dapat melakukan beberapa penyetelan untuk masa depan.

Untuk menghasilkan beban, alat yang biasa dipilih - Apache Jmetr. Itu saja cukup bagus, karena saya menulis beberapa artikel kembali, dan ini adalah salah satu solusi yang paling fleksibel di pasar, meskipun Jawa suka makan. Untuk bekerja dengan S3, kami menggunakan modul yang ditulis sendiri menggunakan AWS SDK, juga di Jawa. Dalam pengujian, kami dapat mencapai kecepatan 12,5 Gbps untuk menulis file lebih dari 250 megabita dengan pemuatan paralel dengan potongan 5 megabita, dan untuk file kurang dari 5 megabita - memproses sekitar 3000 permintaan HTTP per detik. Saat menjalankan kedua tes secara paralel, ternyata 11 Gigabits dan 2200 permintaan per detik. Pada saat yang sama, ada kemungkinan meningkatkan pekerjaan dengan beban campuran dan dengan benda-benda kecil. Kami "mengubur" dalam CPU, dan soket kedua gratis. Pada generator beban, file uji diambil dari RAM untuk mengecualikan pengaruh pada hasil subsistem disk generator itu sendiri. Untuk pengujian, mengingat kecintaan Java terhadap RAM dan kebutuhan untuk bekerja dengan sejumlah besar utas selama pemuatan paralel, kami menggunakan server HP DL980 g7 sebagai generator. Ini adalah server delapan unit dengan 8 prosesor Intel E7-4870 dan RAM 512Gb on board.

Di dalam tim, nama panggilan Behemoth yang penuh kasih sayang menempel padanya.


14. Kuda nil kami. Benar, sesuatu yang mirip?


15. Tampak belakang. Kabel yang menakutkan di bagian tengah bawah adalah koneksi silang dari bus jembatan internal


16. Ini adalah salah satu dari dua tujuan server. Masing-masing memiliki 4 prosesor dan 16 slot RAM 16 gigabita


17. Untuk menggunakan Htop dengan nyaman di konsol server seperti itu, Anda memerlukan monitor besar :)

Dalam prakteknya, tes campuran telah terlihat bahkan memuat server yang sangat kuat.
Untuk mencapai hasil kinerja yang diperoleh, kami harus mentransfer jaringan internal cluster ke frame jumbo 9k dan sedikit menyetel tumpukan jaringan penyeimbang dan simpul kerja (kami menggunakan CentOS Linux), serta mengoptimalkan sejumlah parameter kernel lainnya pada simpul kerja:

 cat /etc/sysctl.conf … kernel.printk = 3 4 1 7 read_ahead_kb = 1024 write_expire = 250 read_expire = 250 fifo_batch = 128 front_merges = 0 net.core.wmem_default = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 16777216 net.core.rmem_max = 16777216 net.core.somaxconn = 5120 net.core.netdev_max_backlog = 50000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_max_syn_backlog = 30000 net.ipv4.tcp_max_tw_buckets = 2000000 fs.file-max = 196608 vm.overcommit_memory = 1 vm.overcommit_ratio = 100 vm.max_map_count = 65536 vm.dirty_ratio = 40 vm.dirty_background_ratio = 5 vm.dirty_expire_centisecs = 100 vm.dirty_writeback_centisecs = 100 net.ipv4.tcp_fin_timeout=10 net.ipv4.tcp_congestion_control=htcp net.ipv4.netfilter.ip_conntrack_max=1048576 net.core.rmem_default=65536 net.core.wmem_default=65536 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.ipv4.ip_local_port_range=1024 65535 

Pengaturan utama yang mengalami penyetelan adalah ukuran buffer, jumlah koneksi jaringan, jumlah koneksi ke port dan koneksi yang dipantau oleh firewall, serta timeout.

Cisco C3750 + LACP = sakit
Perangkap lain dalam kinerja jaringan adalah penyeimbangan beban saat menggunakan LACP / LAGp. Sayangnya, Cisco 3750 tidak dapat menyeimbangkan beban lintas port, hanya pada alamat sumber dan tujuan. Untuk mencapai keseimbangan lalu lintas yang benar, saya harus menggantung 12 alamat IP pada ikatan-antarmuka dari node yang bekerja, "melihat" ke arah klien. Persyaratan, 3 untuk setiap tautan fisik. Dengan konfigurasi ini, dimungkinkan untuk melakukannya tanpa LACP pada antarmuka "eksternal" dari node yang berfungsi, karena semua alamat ditentukan dalam konfigurasi Nginx, tetapi jika tautan itu hilang, kami akan secara otomatis mengurangi bobot simpul dalam balancing. Dengan "dump", tautan LACP memungkinkan Anda mempertahankan aksesibilitas penuh ke semua alamat.

 bond0.10  Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1       RX packets:2390824140 errors:0 dropped:0 overruns:0 frame:0       TX packets:947068357 errors:0 dropped:0 overruns:0 carrier:0       collisions:0 txqueuelen:0       RX bytes:18794424755066 (17.0 TiB)  TX bytes:246433289523 (229.5 GiB) bond0.10:0 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:1 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:2 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:3 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:4 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:5 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:6 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:7 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:8 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:9 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XXMask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:10 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 

Pengujian fungsional

Setelah selesai mengerjakan repositori, kami bertemu dengan layanan flexify.io. Mereka membantu memfasilitasi migrasi antara penyimpanan objek yang berbeda. Tetapi untuk menjadi mitra Flexify, Anda harus lulus tes serius. "Kenapa tidak?" - kami pikir. Pengujian pihak ketiga selalu merupakan pengalaman yang bermanfaat.

Tugas utama dari tes ini adalah untuk memverifikasi operasi metode protokol S3 melalui proksi mereka dalam kaitannya dengan berbagai konfigurasi, di antaranya dapat ada set ember yang kompatibel dengan S3 yang didukung oleh penyedia layanan.

Pertama-tama, metode yang bekerja dengan objek dalam ember diperiksa. Penyimpanan kami diuji menggunakan berbagai macam data uji, perilaku metode diuji untuk objek dengan berbagai ukuran dan konten, untuk kunci yang berisi semua jenis kombinasi karakter Unicode.

Dalam tes negatif, mereka mencoba mentransfer data yang tidak valid sedapat mungkin. Perhatian khusus diberikan pada keamanan data dalam proses.

Metode bekerja dengan ember juga telah diuji, tetapi terutama dalam skenario positif. Tujuan dari tes ini adalah untuk memverifikasi bahwa menggunakan metode melalui proxy tidak memerlukan masalah serius, misalnya, korupsi data atau crash.

Luasnya cakupan dapat dinilai dengan tes yang digunakan baik melalui proksi maupun langsung. Sebagian besar tes, terutama yang bekerja dengan objek, memiliki parameter dan menguji sejumlah besar objek yang berbeda, rentang, dll.





Seperti yang Anda duga, ini adalah tes yang cukup sulit, tetapi kami lulus secara umum dengan positif. Beberapa masalah muncul karena kurangnya dukungan untuk SSE dan sekolah kecil dengan dukungan Unicode pada waktu itu:

Gagal memuat dengan kunci yang mengandung:

• U + 0000-U + 001F - 32 karakter kontrol pertama yang tidak dapat dibaca. Di Amazon, misalnya, hanya U + 0000 pertama yang tidak dituangkan secara langsung.
  

• Dan juga U + 18D7C, U + 18DA8, U + 18DB4, U + 18DBA, U + 18DC4, U + 18DCE. Ini juga karakter yang tidak dapat dibaca, tetapi Amazon menerimanya sebagai kunci. Tidak ada masalah dengan semua karakter lainnya.
  

Saat membaca isi ember, ada masalah pada kunci 66.675, yang berisi simbol U + FFFE. Tidak mungkin mendapatkan daftar kunci lengkap dalam ember yang berisi objek dengan kunci semacam itu.

Kalau tidak, pengujiannya berhasil, dan pada akhir September kami muncul dalam daftar pemasok yang tersedia!

Kata penutup dan bonus pendek untuk pembaca

Sebelumnya, saya menulis bahwa Cloudian HyperStore, meskipun memiliki banyak kelebihan, praktis tidak tercakup dalam segmen Internet berbahasa Rusia.

Artikel pertama adalah tentang dasar-dasar bekerja dengan Cloudian. Kami membongkar struktur internal, nuansa arsitektur, dan membaca terjemahan dokumentasi resmi.

Hari ini saya memberi tahu bagaimana kami membangun penyimpanan kami sendiri dan nuansa serta perangkap apa yang kami temui.

Anda yang ingin menyentuh dengan pena apa yang kita bicarakan 2 artikel berturut-turut dapat menggunakan formulir umpan balik di halaman ini dan secara pribadi mencari tahu apa garamnya. Sebagai standar, kami memberikan 15Gb selama 2 minggu gratis, tentu saja, dengan akses pengguna. Jika Anda memiliki keinginan untuk membagikan kesan Anda tentang bekerja dengan repositori, tuliskan kepada saya di PM. :)

Dan bagi mereka yang tidak cukup 15 Gb selama 2 minggu, kami memiliki pencarian kecil! Dalam foto-foto di artikel itu, kami menempatkan tiga kuda nil. 50 orang pertama yang menemukannya akan menerima 30Gb selama 4 minggu. Untuk mendapatkan tes yang diperbesar, tulis komentar di nomor gambar tempat kuda nil bersembunyi, dan ajukan tautan di atas. Jangan lupa untuk menyertakan tautan ke komentar Anda dalam aplikasi.

Secara tradisi, jika Anda memiliki pertanyaan, tanyakan di komentar.
Saya akan dengan senang hati menjawabnya.