Halo, Habr!

Bukan rahasia lagi bahwa sejumlah besar data terlibat dalam pekerjaan aplikasi modern, dan alirannya terus bertambah. Data ini perlu disimpan dan diproses, seringkali dari sejumlah besar mesin, dan ini bukan tugas yang mudah. Untuk mengatasinya, ada toko objek cloud. Biasanya mereka adalah implementasi dari teknologi Storage Ditentukan Perangkat Lunak.

Pada awal 2018, kami meluncurkan (dan meluncurkan!) Penyimpanan kami yang kompatibel dengan S3 100% berdasarkan Cloudian HyperStore. Ternyata, jaringan memiliki sangat sedikit publikasi berbahasa Rusia tentang Cloudian itu sendiri, dan lebih sedikit lagi tentang aplikasi aktual dari solusi ini.

Hari ini, berdasarkan pengalaman DataLine, saya akan memberi tahu Anda tentang arsitektur dan struktur internal perangkat lunak Cloud, termasuk implementasi Cloudian SDS berdasarkan sejumlah solusi arsitektur Apache Cassandra. Secara terpisah, kami menganggap yang paling menarik dalam penyimpanan SDS - logika memastikan toleransi kesalahan dan distribusi objek.

Jika Anda sedang membangun penyimpanan S3 Anda atau sibuk mempertahankannya, artikel ini akan berguna bagi Anda.

Pertama-tama, saya akan menjelaskan mengapa pilihan kita jatuh pada Cloudian. Ini sederhana: ada beberapa opsi yang layak di ceruk ini. Sebagai contoh, beberapa tahun yang lalu, ketika kami hanya berpikir untuk membangun, hanya ada tiga pilihan:

• CEHP + RADOS Gateway;
  
• Minio
  
• Cloudian HyperStore.
  

Bagi kami, sebagai penyedia layanan, faktor yang menentukan adalah: tingkat korespondensi yang tinggi antara API penyimpanan dan Amazon S3 asli, ketersediaan penagihan bawaan, skalabilitas dengan dukungan multiregionalitas, dan keberadaan lini ketiga dukungan vendor. Cloudian memiliki semua ini.

Dan ya, yang paling (pasti!) Yang paling penting adalah bahwa DataLine dan Cloudian memiliki warna korporat yang sama. Anda harus mengakui bahwa kami tidak dapat menahan keindahan itu.



Sayangnya, Cloudian bukan perangkat lunak yang paling umum, dan praktis tidak ada informasi tentang itu di RuNet. Hari ini kami akan memperbaiki ketidakadilan ini dan berbicara dengan Anda tentang fitur-fitur arsitektur HyperStore, memeriksa komponen-komponennya yang paling penting dan berurusan dengan nuansa arsitektur utama. Mari kita mulai dengan yang paling mendasar, yaitu - apa itu Cloudian di bawah tenda?

Bagaimana Cloudian HyperStore Storage Bekerja

Mari kita lihat diagram dan melihat bagaimana solusi Cloudian bekerja.


Skema penyimpanan komponen utama.

Seperti yang dapat kita lihat, sistem terdiri dari beberapa komponen utama:

• Kontrol Manajemen Cloudian - konsol manajemen ;
• Layanan Admin - modul administrasi internal ;
• Layanan S3 - modul yang bertanggung jawab untuk mendukung protokol S3 ;
• Layanan HyperStore - layanan penyimpanan aktual ;
• Apache Cassandra - repositori terpusat dari data layanan ;
• Redis - untuk data yang paling sering dibaca .

Yang paling menarik bagi kami adalah karya layanan utama, Layanan S3 dan Layanan HyperStore, maka kami akan mempertimbangkan pekerjaan mereka dengan cermat. Tetapi pertama-tama, masuk akal untuk mengetahui bagaimana distribusi layanan dalam cluster diatur dan apa toleransi kesalahan dan keandalan penyimpanan data dari solusi ini secara keseluruhan.




Yang dimaksud dengan layanan umum pada diagram di atas adalah layanan S3, HyperStore, CMC dan Apache Cassandra . Sepintas, semuanya indah dan rapi. Tetapi setelah pemeriksaan lebih dekat, ternyata hanya satu kegagalan simpul yang secara efektif berhasil. Dan kehilangan simultan dua node sekaligus bisa berakibat fatal bagi ketersediaan cluster - Redis QoS (pada node 2) hanya memiliki 1 slave (pada node 3). Gambar yang sama dengan risiko kehilangan manajemen cluster - Server Wayang hanya pada dua node (1 dan 2). Namun, probabilitas kegagalan dua node sekaligus sangat rendah, dan Anda dapat hidup dengannya.

Namun demikian, untuk meningkatkan keandalan penyimpanan, kami menggunakan 4 node di DataLine alih-alih minimal tiga. Distribusi sumber daya berikut diperoleh:



Satu lagi nuansa segera menarik perhatian Anda - Redis Kredensial tidak ditempatkan pada setiap node (seperti yang dapat diasumsikan dari skema resmi di atas), tetapi hanya pada 3 dari mereka. Dalam hal ini, Redis Credentials digunakan untuk setiap permintaan yang masuk. Ternyata karena kebutuhan untuk pergi ke Redis orang lain, ada beberapa ketidakseimbangan dalam kinerja simpul keempat.

Bagi kami, ini belum signifikan. Selama pengujian stres, penyimpangan yang signifikan dalam kecepatan respon dari node tidak diperhatikan, tetapi pada kelompok besar dari puluhan node yang bekerja, masuk akal untuk memperbaiki nuansa ini.

Beginilah skema migrasi pada 6 node terlihat seperti:



Diagram menunjukkan bagaimana migrasi layanan diimplementasikan jika terjadi kegagalan simpul. Hanya kegagalan satu server dari setiap peran yang diperhitungkan. Jika kedua server jatuh, intervensi manual akan diperlukan.

Di sini juga, bisnis itu bukannya tanpa kehalusan. Migrasi peran menggunakan Wayang. Oleh karena itu, jika Anda kehilangan atau memecahkannya secara tidak sengaja, kegagalan otomatis mungkin tidak berfungsi. Untuk alasan yang sama, Anda tidak boleh mengedit manifes wayang bawaan secara manual. Ini tidak sepenuhnya aman, perubahan dapat tiba-tiba usang, karena manifes diedit menggunakan panel admin cluster.

Dari sudut pandang keamanan data, semuanya jauh lebih menarik. Metadata objek disimpan di Apache Cassandra, dan setiap catatan direplikasi menjadi 3 dari 4 node. Faktor replikasi 3 juga digunakan untuk menyimpan data, tetapi Anda dapat mengkonfigurasi yang lebih besar. Ini memastikan keamanan data bahkan dalam kasus kegagalan simultan 2 dari 4 node. Dan jika Anda punya waktu untuk menyeimbangkan kembali cluster, Anda tidak akan kehilangan apa pun dengan satu simpul yang tersisa. Hal utama adalah memiliki ruang yang cukup.



Inilah yang terjadi ketika dua node gagal. Diagram dengan jelas menunjukkan bahwa bahkan dalam situasi ini, data tetap aman

Pada saat yang sama, ketersediaan data dan penyimpanan akan tergantung pada strategi untuk memastikan konsistensi. Untuk data, metadata, baca dan tulis, ini dikonfigurasi secara terpisah.

Opsi yang valid setidaknya satu node, kuorum, atau semua node.
Pengaturan ini menentukan berapa banyak node yang harus mengkonfirmasi penulisan / baca agar permintaan dianggap berhasil. Kami menggunakan kuorum sebagai kompromi yang masuk akal antara waktu yang dibutuhkan untuk memproses permintaan dan keandalan penulisan / inkonsistensi membaca. Yaitu, dari tiga node yang terlibat dalam operasi, untuk operasi bebas kesalahan, cukup untuk mendapatkan jawaban yang konsisten dari 2. Dengan demikian, untuk tetap bertahan jika terjadi kegagalan lebih dari satu node, Anda harus beralih ke strategi tulis / baca tunggal.

Pemrosesan permintaan dalam Cloudian

Di bawah ini kami akan mempertimbangkan dua skema untuk memproses permintaan masuk di Cloudian HyperStore, PUT dan GET. Ini adalah tugas utama untuk Layanan S3 dan HyperStore.

Mari kita mulai dengan bagaimana permintaan penulisan diproses:



Tentunya Anda mencatat bahwa setiap permintaan menghasilkan banyak pemeriksaan dan pengambilan data, setidaknya 6 hit dari komponen ke komponen. Dari sinilah penundaan perekaman dan konsumsi waktu CPU tinggi muncul ketika bekerja dengan file kecil.

File besar ditransmisikan oleh potongan. Potongan terpisah tidak dianggap sebagai permintaan terpisah dan beberapa pemeriksaan tidak dilakukan.

Node yang menerima permintaan awal lebih jauh menentukan secara mandiri di mana dan apa yang harus ditulis, bahkan jika tidak ditulis langsung ke sana. Ini memungkinkan Anda untuk menyembunyikan organisasi internal cluster dari klien akhir dan menggunakan penyeimbang beban eksternal. Semua ini berpengaruh positif terhadap kemudahan perawatan dan toleransi kesalahan penyimpanan.



Seperti yang Anda lihat, logika membaca tidak terlalu berbeda dari menulis. Di dalamnya, sensitivitas kinerja tinggi yang sama terhadap ukuran objek yang diproses diamati. Oleh karena itu, karena penghematan yang signifikan dalam bekerja dengan metadata, jauh lebih mudah untuk mengekstrak satu objek yang dicincang halus daripada banyak objek terpisah dari volume total yang sama.

Penyimpanan dan duplikasi data

Seperti yang dapat Anda lihat dari diagram di atas, Cloudian mendukung berbagai skema penyimpanan dan duplikasi data:

Replikasi - menggunakan replikasi, dimungkinkan untuk mempertahankan jumlah salinan kustom dari setiap objek data dalam sistem dan menyimpan setiap salinan pada node yang berbeda. Misalnya, menggunakan replikasi 3X, 3 salinan dari setiap objek dibuat, dan setiap salinan "terletak" pada node sendiri.

Erasure Coding - Dengan pengkodean erasure, setiap objek dikodekan ke dalam jumlah khusus (dikenal sebagai nomor K) dari fragmen data ditambah jumlah kustom kode redundansi (nomor M). Setiap fragmen K + M dari suatu objek adalah unik, dan setiap fragmen disimpan pada simpulnya sendiri. Objek dapat didekodekan menggunakan fragmen K apa pun. Dengan kata lain, objek tetap dapat dibaca, bahkan jika node M tidak dapat diakses.

Misalnya, dalam pengkodean penghapusan, sesuai dengan rumus 4 + 2 (4 fragmen data ditambah 2 fragmen kode redundansi), setiap objek dibagi menjadi 6 fragmen unik yang disimpan pada enam node berbeda, dan objek ini dapat dipulihkan dan dibaca jika ada 4 dari 6 fragmen yang tersedia .

Keuntungan dari Erasure Coding dibandingkan dengan replikasi adalah untuk menghemat ruang, meskipun dengan biaya peningkatan beban prosesor yang signifikan, memburuknya kecepatan respons dan perlunya prosedur latar belakang untuk mengontrol konsistensi objek. Bagaimanapun, metadata disimpan secara terpisah dari data (dalam Apache Cassandra), yang meningkatkan fleksibilitas dan keandalan solusi.

Secara singkat tentang fungsi lain dari HyperStore

Seperti yang saya tulis di awal artikel ini, beberapa alat yang berguna dibangun ke HyperStore. Diantaranya adalah:

• Tagihan fleksibel dengan dukungan untuk mengubah harga sumber daya tergantung pada volume dan rencana tarif;
  
• Pemantauan internal
  
• Kemampuan untuk membatasi penggunaan sumber daya untuk pengguna dan grup pengguna;
  
• Pengaturan QoS dan prosedur bawaan untuk menyeimbangkan penggunaan sumber daya antara node, serta prosedur reguler untuk menyeimbangkan kembali antara node dan disk pada node atau ketika memasukkan node baru dalam sebuah cluster.
  

Namun, Cloudian HyperStore masih belum sempurna. Misalnya, karena alasan tertentu, Anda tidak dapat mentransfer akun yang ada ke grup lain atau menetapkan beberapa grup ke satu catatan. Laporan tagihan sementara tidak mungkin - Anda akan menerima semua laporan hanya setelah menutup periode pelaporan. Oleh karena itu, baik klien maupun kami tidak dapat mengetahui berapa banyak akun telah tumbuh secara real time.

Cloudian HyperStore Logic

Sekarang kita akan menyelam lebih dalam dan melihat yang paling menarik dalam penyimpanan SDS - logika distribusi objek dengan node. Dalam kasus penyimpanan Cloudian, metadata disimpan secara terpisah dari data itu sendiri. Untuk metadata, Cassandra digunakan, untuk data, solusi HyperStore.

Sayangnya, sejauh ini tidak ada terjemahan resmi dari dokumentasi Cloudian ke dalam bahasa Rusia di Internet, jadi di bawah ini saya akan memposting terjemahan saya dari bagian yang paling menarik dari dokumentasi ini.

Peran Apache Cassandra dalam HyperStore

Dalam HyperStore, Cassandra digunakan untuk menyimpan metadata objek, informasi akun pengguna, dan data penggunaan layanan. Dalam penyebaran khas pada setiap HyperStore, data Cassandra disimpan pada drive yang sama dengan OS. Sistem ini juga mendukung data Cassandra pada drive khusus pada setiap node. Data Cassandra tidak disimpan di disk data HyperStore. Ketika vNodes ditugaskan ke host, mereka didistribusikan hanya ke node penyimpanan HyperStore. vNodes tidak dialokasikan ke drive tempat data Cassandra disimpan.
Di dalam cluster, metadata di Cassandra direplikasi sesuai dengan kebijakan (strategi) repositori Anda. Replikasi Data Cassandra menggunakan vNodes dengan cara ini:

• Saat membuat objek Cassandra baru (kunci utama dan nilai-nilai yang terkait), itu hash, dan hash digunakan untuk mengaitkan objek dengan vNode tertentu. Sistem memeriksa host yang vNode ini ditugaskan, dan kemudian replika pertama objek Cassandra disimpan pada drive Cassandra pada host itu.
  
• Sebagai contoh, misalkan sebuah host ditugaskan 96 vNodes didistribusikan di beberapa disk data HyperStore. Objek-objek Cassandra yang nilai hash-nya berada dalam rentang token dari 96 vNodes ini akan ditulis ke drive Cassandra pada host ini.
  
• Replika tambahan dari objek Cassandra (jumlah replika tergantung pada konfigurasi Anda) dikaitkan dengan vNodes dengan nomor urut berikut dan disimpan pada node tempat vNodes ini ditetapkan, asalkan vNodes dilewati jika perlu, sehingga setiap replika objek Cassandra disimpan pada yang lain mesin host.
  

Cara Penyimpanan HyperStore Bekerja

Penempatan dan replikasi objek S3 dalam cluster HyperStore didasarkan pada skema caching yang konsisten yang menggunakan ruang token integer dalam rentang dari 0 hingga 2 ¹²⁷ -1. Token integer ditetapkan ke node HyperStore. Untuk setiap objek S3, hash dihitung saat dimuat ke penyimpanan. Objek disimpan dalam node yang diberi nilai token terendah, lebih besar dari atau sama dengan nilai hash objek. Replikasi juga diimplementasikan dengan menyimpan objek pada node yang telah diberi token, yang memiliki nilai minimum.

Dalam penyimpanan berbasis hash konsisten "klasik", satu token ditugaskan ke satu simpul fisik. Sistem Cloudian HyperStore menggunakan dan memperluas fungsionalitas "simpul virtual" (vNode) yang diperkenalkan di Cassandra dalam versi 1.2 - sejumlah besar token ditugaskan untuk masing-masing host fisik (maksimum 256). Bahkan, cluster penyimpanan terdiri dari sejumlah besar "virtual node" dengan sejumlah besar virtual node (token) pada setiap host fisik.

Sistem HyperStore menetapkan satu set token yang terpisah (virtual node) untuk setiap disk pada setiap host fisik. Setiap disk pada host bertanggung jawab atas set replika objeknya sendiri. Kegagalan disk hanya memengaruhi replika objek yang ada di dalamnya. Drive lain pada host akan terus beroperasi dan melaksanakan tanggung jawab penyimpanan data mereka.

Kami memberikan contoh dan mempertimbangkan sekelompok 6 host HyperStore, yang masing-masing memiliki 4 disk penyimpanan S3. Asumsikan 32 token ditugaskan untuk setiap host fisik dan ada ruang token yang disederhanakan dari 0 hingga 960, dan nilai 192 token dalam sistem ini (6 host dari 32 token) adalah 0, 5, 10, 15, 20, dan seterusnya hingga 955.

Diagram di bawah ini menunjukkan satu kemungkinan distribusi token di seluruh cluster. 32 token dari setiap host didistribusikan secara merata di 4 disk (8 token per disk), dan token itu sendiri didistribusikan secara acak di seluruh cluster.



Sekarang anggaplah Anda mengkonfigurasi HyperStore ke 3X mereplikasi objek S3. Mari kita sepakat bahwa objek S3 dimuat ke dalam sistem, dan algoritma hash yang diterapkan pada namanya memberi kita nilai hash 322 (dalam ruang hash yang disederhanakan ini). Diagram di bawah ini menunjukkan bagaimana tiga instance atau replika objek akan disimpan dalam sebuah cluster:

• Dengan nilai hash nama 322, replika pertama objek disimpan di 325 token, karena ini adalah nilai token terkecil yang lebih besar dari atau sama dengan nilai hash objek. 325 token (disorot dengan warna merah pada diagram) ditugaskan untuk hyperstore2: Disk2. Dengan demikian, replika pertama objek disimpan di sana.
  

• Replika kedua disimpan di disk yang ditugaskan token berikutnya (330, disorot dalam oranye), yaitu, di hyperstore4: Disk2.
  
• Replika ketiga disimpan ke disk, yang diberikan token berikutnya setelah 330 - 335 (kuning), di hyperstore3: Disk3.
  

Saya akan menambahkan komentar: dari sudut pandang praktis, optimisasi ini (distribusi token tidak hanya di antara node fisik, tetapi juga antar disk individu) diperlukan tidak hanya untuk memastikan aksesibilitas, tetapi juga untuk memastikan distribusi data yang seragam antara disk. Dalam hal ini, array RAID tidak digunakan, seluruh logika alokasi data pada disk dikendalikan oleh HyperStore itu sendiri. Di satu sisi, itu nyaman dan terkendali, jika disk hilang, semuanya akan diseimbangkan sendiri. Di sisi lain, saya pribadi mempercayai pengontrol RAID yang lebih baik - lagipula, logikanya telah dioptimalkan selama bertahun-tahun. Tapi ini semua preferensi pribadi saya, pada tiang dan masalah nyata, kami tidak pernah menangkap HyperStore, jika kami mengikuti rekomendasi vendor ketika menginstal perangkat lunak pada server fisik. Tetapi upaya untuk menggunakan virtualisasi dan disk virtual di atas bulan yang sama pada sistem penyimpanan gagal, ketika membebani sistem penyimpanan selama pengujian beban, HyperStore menjadi gila dan menyebarkan data sepenuhnya tidak merata, menyumbat beberapa disk dan tidak menyentuh yang lain.

Drive perangkat di dalam sebuah cluster

Ingatlah bahwa setiap host memiliki 32 token, dan token dari masing-masing host didistribusikan secara merata di antara disk-nya. Mari kita lihat lebih dekat pada hyperstore2: Disk2 (pada diagram di bawah). Kita melihat bahwa token 325, 425, 370 dan seterusnya ditugaskan ke disk ini.

Karena cluster dikonfigurasi untuk replikasi 3X, berikut ini akan disimpan di hyperstore2: Disk2:

Sesuai dengan 325 token disk:

• Replika objek pertama dengan nilai hash dari 320 (eksklusif) hingga 325 (inklusif);
• Replika objek kedua dengan nilai hash dari 315 (eksklusif) hingga 320 (inklusif);
• Replika objek ketiga dengan nilai hash dari 310 (eksklusif) hingga 315 (inklusif).

Menurut 425 token disk:

• Replika objek pertama dengan nilai hash dari 420 (eksklusif) hingga 425 (inklusif);
• Replika objek kedua dengan nilai hash dari 415 (eksklusif) ke 420 (inklusif);
• Replika objek ketiga dengan nilai hash dari 410 (eksklusif) hingga 415 (inklusif).

Dan sebagainya.

Seperti disebutkan sebelumnya, ketika menempatkan replika kedua dan ketiga, HyperStore dalam beberapa kasus dapat melewatkan token agar tidak menyimpan lebih dari satu salinan objek pada satu simpul fisik. Ini menghilangkan penggunaan hyperstore2: disk2 sebagai penyimpanan untuk replika kedua atau ketiga dari objek yang sama.



Jika Disk 2 crash pada Disk 1, 3, dan 4, data akan terus disimpan, dan objek pada Disk 2 akan disimpan di cluster, karena telah direplikasi ke host lain.

Komentar: sebagai hasilnya, distribusi replika dan / atau fragmen objek di cluster HyperStore didasarkan pada desain Cassandra, yang dikembangkan untuk kebutuhan penyimpanan file. , , , , «» . . . , : , , .

Sekarang mari kita lihat bagaimana HyperStore bekerja di beberapa pusat data dan wilayah. Dalam kasus kami, mode multi-DPC berbeda dari mode multi-regional dengan menggunakan satu atau beberapa ruang token. Dalam kasus pertama, ruang token seragam. Pada tahap kedua, setiap wilayah akan memiliki ruang token independen dengan (berpotensi) pengaturannya sendiri untuk tingkat konsistensi, kapasitas, dan konfigurasi penyimpanan.
Untuk memahami bagaimana ini bekerja, mari kita kembali ke terjemahan dokumentasi, bagian "Penyebaran Pusat Data Banyak".

Pertimbangkan untuk menggunakan HyperStore di dua pusat data. Sebut mereka DC1 dan DC2. Setiap pusat data memiliki 3 node fisik. Seperti dalam contoh kami sebelumnya, setiap node fisik memiliki empat disk, 32 token (vNodes) ditugaskan untuk setiap host, dan kami menganggap ruang token yang disederhanakan dari 0 hingga 960. Menurut skenario ini dengan beberapa pusat data, ruang token dibagi menjadi 192 token - 32 token untuk masing-masing dari 6 host fisik. Token didistribusikan oleh host secara acak.

Anggap juga bahwa replikasi objek S3 dalam hal ini dikonfigurasi pada dua replika di setiap pusat data.

Mari kita lihat bagaimana objek S3 hipotetis dengan nilai hash 942 akan mereplikasi di 2 pusat data:

• vNode 945 ( ), DC2, hyperstore5:Disk3.
  
• vNode 950 ( ) DC2, hyperstore6:Disk4.
  
• vNode 955 DC2, , vNode .
  
• vNode 0 () — DC1, hyperstore2:Disk3. , (955) (0).
  
• vNode (5) DC2, , vNode .
  
• vNode 10 () — DC1, hyperstore3:Disk3.
  

: , , , , . , .

Ini menyimpulkan tinjauan umum kami tentang arsitektur Cloudian dan fitur-fitur utama. Bagaimanapun, topik ini terlalu serius dan besar untuk bisa memuat manual lengkap menjadi sebuah artikel tentang Habré. Karena itu, jika Anda tertarik pada detail yang saya hilangkan, Anda memiliki pertanyaan atau saran untuk presentasi materi di artikel mendatang, saya akan dengan senang hati berkomunikasi dengan Anda di komentar.
Pada artikel selanjutnya, kami akan mempertimbangkan implementasi penyimpanan S3 di DataLine, kami akan berbicara secara rinci tentang infrastruktur dan teknologi toleransi kesalahan jaringan yang digunakan, dan sebagai bonus, saya akan menceritakan kisah pembangunannya!