Teman sekelas adalah pengguna terbesar Apache Cassandra di RuNet dan salah satu yang terbesar di dunia. Kami mulai menggunakan Cassandra pada 2010 untuk menyimpan perkiraan foto, dan sekarang Cassandra mengelola petabyte data pada ribuan node, apalagi, kami bahkan mengembangkan
database transaksional NewSQL kami sendiri.
Pada 12 September, di kantor St. Petersburg kami, kami akan mengadakan
pertemuan kedua yang didedikasikan untuk Apache Cassandra . Pembicara utama acara ini adalah kepala insinyur Odnoklassnikov Oleg Anastasiev. Oleg adalah seorang ahli di bidang sistem terdistribusi dan toleransi kesalahan, ia telah bekerja dengan Cassandra selama lebih dari 10 tahun dan telah berulang kali
berbicara tentang fitur-fitur produk ini di konferensi .
Menjelang pertemuan, kami berbicara dengan Oleg tentang toleransi kesalahan sistem terdistribusi dengan Cassandra, bertanya apa yang akan ia bicarakan di pertemuan itu dan mengapa patut menghadiri acara ini.
Oleg memulai karirnya sebagai programmer pada tahun 1995. Perangkat lunak yang dikembangkan di sektor perbankan, telekomunikasi, transportasi. Dia telah bekerja sebagai pengembang utama di Odnoklassniki sejak 2007 sebagai bagian dari tim platform. Tanggung jawabnya meliputi pengembangan arsitektur dan solusi untuk sistem beban tinggi, gudang data besar, memecahkan masalah produktivitas dan keandalan portal. Dia juga terlibat dalam pengembang pelatihan dalam perusahaan.
- Oleg, halo! Pada bulan Mei, pertemuan pertama yang didedikasikan untuk Apache Cassandra berlangsung, para peserta mengatakan bahwa diskusi berlangsung hingga larut malam, tolong katakan padaku, apa kesan Anda tentang pertemuan pertama?Pengembang dengan latar belakang berbeda dari berbagai perusahaan datang dengan rasa sakit mereka, solusi tak terduga untuk masalah dan kisah luar biasa. Kami dapat melakukan sebagian besar pertemuan dalam format diskusi, tetapi ada begitu banyak diskusi sehingga kami hanya dapat menyentuh sepertiga dari topik yang diuraikan. Kami memberi banyak perhatian pada bagaimana dan apa yang kami monitor menggunakan layanan produksi nyata kami sebagai contoh.
Saya tertarik dan sangat menikmatinya.
- Dilihat dari pengumuman, mitap kedua akan sepenuhnya dikhususkan untuk toleransi kesalahan, mengapa Anda memilih topik ini?Cassandra adalah sistem terdistribusi yang umum dimuat dengan sejumlah besar fungsi selain melayani permintaan pengguna secara langsung: gosip, deteksi kegagalan, distribusi perubahan skema, memperluas / mengurangi kluster, anti-entropi, cadangan dan pemulihan, dll. Seperti dalam sistem terdistribusi, dengan peningkatan jumlah besi, kemungkinan kegagalan meningkat, sehingga operasi produksi cluster Cassandra memerlukan pemahaman yang mendalam tentang perangkatnya untuk memprediksi perilaku jika terjadi kegagalan dan tindakan operator. Dalam proses menggunakan Cassandra selama bertahun-tahun, kami
telah mengumpulkan keahlian yang signifikan , yang siap kami bagikan, dan juga ingin membahas bagaimana rekan kerja kami memecahkan masalah yang khas.
- Ketika datang ke Cassandra, apa yang Anda maksud dengan toleransi kesalahan?Pertama-tama, tentu saja, kemampuan sistem untuk bertahan dari kegagalan perangkat keras yang khas: hilangnya mesin, disk, atau konektivitas jaringan dengan node / pusat data. Tetapi topik itu sendiri jauh lebih luas dan, khususnya, mencakup pemulihan dari kegagalan, termasuk kegagalan, di mana orang jarang dipersiapkan, misalnya, kesalahan operator.
- Bisakah Anda memberikan contoh cluster data yang paling banyak dimuat dan terbesar?Salah satu cluster terbesar kami adalah cluster hadiah: lebih dari 200 node dan ratusan TB data. Tetapi ini bukan yang paling dimuat, karena ditutupi oleh cache terdistribusi. Cluster tersibuk kami menampung puluhan ribu RPS untuk menulis dan ribuan RPS untuk membaca.
- Wow! Seberapa sering sesuatu pecah?Ya, terus-menerus ! Secara total, kami memiliki lebih dari 6 ribu server, dan setiap minggu beberapa server dan beberapa lusinan disk diganti (tanpa mempertimbangkan proses peningkatan paralel dan penambahan armada). Untuk setiap jenis kegagalan, instruksi yang jelas ditulis tentang apa dan apa yang harus dilakukan, semuanya otomatis jika memungkinkan, oleh karena itu kegagalan adalah rutin dan dalam 99% kasus terjadi tanpa disadari oleh pengguna.
- Apa yang kamu hadapi dengan kegagalan seperti itu?Dari awal pengoperasian Cassandra dan insiden pertama, kami mengerjakan mekanisme pencadangan dan pemulihan dari mereka, membangun prosedur penyebaran yang memperhitungkan keadaan cluster Cassandra dan, misalnya, mencegah node memulai kembali jika kehilangan data dimungkinkan. Kami berencana untuk membicarakan semua ini pada pertemuan tersebut.
- Seperti yang Anda katakan, sistem yang benar-benar andal tidak ada. Jenis kegagalan apa yang Anda persiapkan dan mampu bertahan?Jika kita berbicara tentang instalasi cluster Cassandra kita, pengguna tidak akan melihat apa-apa jika kita kehilangan beberapa mesin dalam satu DC atau seluruh DC (ini terjadi). Dengan meningkatnya jumlah DC, kami berpikir untuk mulai memastikan pengoperasian jika terjadi kegagalan dua DC.
- Menurut Anda apa yang tidak dimiliki Cassandra dalam hal toleransi kesalahan?Cassandra, seperti banyak repositori NoSQL awal lainnya, membutuhkan pemahaman mendalam tentang struktur internal dan proses dinamis yang sedang berlangsung. Saya akan mengatakan bahwa dia tidak memiliki kesederhanaan, prediktabilitas, dan dapat diamati. Tetapi akan menarik untuk mendengar pendapat dari peserta pertemuan lainnya!
Oleg, terima kasih banyak telah meluangkan waktu untuk menjawab pertanyaan!
Kami menunggu semua orang yang ingin berbicara dengan para ahli di bidang pengoperasian Apache Cassandra pada pertemuan pada 12 September di kantor St. Petersburg mereka.
Ayo, ini akan menarik!
Daftarkan untuk acara tersebut.