Odnoklassniki ialah pengguna terbesar Apache Cassandra di RuNet dan salah satu yang terbesar di dunia. Kami mula menggunakan Cassandra pada tahun 2010 untuk menyimpan penarafan foto, dan kini Cassandra menguruskan petabait data pada beribu-ribu nod, malah, kami membangunkan sendiri .
Pada 12 September di pejabat St. Petersburg kami akan mengadakannya . Penceramah utama acara itu akan menjadi ketua jurutera Odnoklassniki Oleg Anastasyev. Oleg adalah pakar dalam bidang sistem teragih dan toleran kesalahan; dia telah bekerja dengan Cassandra selama lebih dari 10 tahun dan berulang kali .
Pada malam sebelum pertemuan itu, kami bercakap dengan Oleg tentang toleransi kesalahan sistem yang diedarkan dengan Cassandra, bertanya apa yang akan dibincangkan pada pertemuan itu dan mengapa ia berbaloi untuk menghadiri acara ini.
Oleg memulakan kerjaya pengaturcaraannya pada tahun 1995. Beliau membangunkan perisian dalam perbankan, telekomunikasi, dan pengangkutan. Beliau telah bekerja sebagai pembangun terkemuka di Odnoklassniki sejak 2007 dalam pasukan platform. Tanggungjawabnya termasuk membangunkan seni bina dan penyelesaian untuk sistem beban tinggi, gudang data yang besar, dan menyelesaikan masalah prestasi dan kebolehpercayaan portal. Beliau juga melatih pemaju dalam syarikat itu.
- Oleg, hello! Pada bulan Mei berlaku , didedikasikan untuk Apache Cassandra, para peserta mengatakan bahawa perbincangan berlangsung sehingga larut malam, sila beritahu saya, apakah tanggapan anda tentang pertemuan pertama?
Pembangun dengan latar belakang yang berbeza dari syarikat yang berbeza datang dengan kesakitan mereka sendiri, penyelesaian yang tidak dijangka untuk masalah dan cerita yang menakjubkan. Kami berjaya mengendalikan kebanyakan pertemuan dalam format perbincangan, tetapi terdapat begitu banyak perbincangan sehingga kami hanya dapat menyentuh satu pertiga daripada topik yang dirancang. Kami memberi banyak perhatian kepada cara dan perkara yang kami pantau menggunakan contoh perkhidmatan pengeluaran sebenar kami.
Saya tertarik dan sangat menyukainya.
- Berdasarkan pengumuman itu, akan menumpukan sepenuhnya kepada toleransi kesalahan, mengapa anda memilih topik ini?
Cassandra ialah sistem pengedaran biasa yang sibuk dengan sejumlah besar fungsi melangkaui permintaan pengguna secara langsung: gosip, pengesanan kegagalan, penyebaran perubahan skema, pengembangan/pengurangan kelompok, anti-entropi, sandaran dan pemulihan, dsb. Seperti dalam mana-mana sistem yang diedarkan, apabila jumlah perkakasan meningkat, kemungkinan kegagalan meningkat, jadi pengendalian kluster pengeluaran Cassandra memerlukan pemahaman yang mendalam tentang strukturnya untuk meramalkan tingkah laku sekiranya berlaku kegagalan dan tindakan pengendali. Selepas menggunakan Cassandra selama bertahun-tahun, kami , yang kami sedia berkongsi, dan kami juga ingin membincangkan cara rakan sekerja di kedai menyelesaikan masalah biasa.
β Apabila bercakap tentang Cassandra, apakah yang anda maksudkan dengan toleransi kesalahan?
Pertama sekali, sudah tentu, keupayaan sistem untuk bertahan daripada kegagalan perkakasan biasa: kehilangan mesin, cakera atau sambungan rangkaian dengan nod/pusat data. Tetapi topik itu sendiri adalah lebih luas dan khususnya termasuk pemulihan daripada kegagalan, termasuk kegagalan yang jarang disediakan oleh orang ramai, contohnya, kesilapan operator.
β Bolehkah anda memberikan contoh kelompok data yang paling banyak dimuatkan dan terbesar?
Salah satu kluster terbesar kami ialah kluster hadiah: lebih daripada 200 nod dan ratusan TB data. Tetapi ia bukan yang paling dimuatkan, kerana ia dilindungi oleh cache yang diedarkan. Kelompok tersibuk kami mengendalikan puluhan ribu RPS untuk menulis dan ribuan RPS untuk membaca.
- Wah! Berapa kerap sesuatu pecah?
! Secara keseluruhan, kami mempunyai lebih daripada 6 ribu pelayan, dan setiap minggu beberapa pelayan dan beberapa dozen cakera diganti (tanpa mengambil kira proses selari peningkatan dan pengembangan armada mesin). Untuk setiap jenis kegagalan, terdapat arahan yang jelas tentang perkara yang perlu dilakukan dan mengikut susunan, semuanya diautomasikan apabila mungkin, jadi kegagalan adalah rutin dan dalam 99% kes berlaku tanpa disedari oleh pengguna.
β Bagaimanakah anda menangani penolakan sedemikian?
Sejak awal operasi Cassandra dan insiden pertama, kami mengusahakan mekanisme untuk sandaran dan pemulihan daripadanya, membina prosedur penggunaan yang mengambil kira keadaan gugusan Cassandra dan, sebagai contoh, tidak membenarkan nod dimulakan semula jika kehilangan data mungkin. Kami merancang untuk bercakap tentang semua ini pada pertemuan itu.
β Seperti yang anda katakan, tiada sistem yang boleh dipercayai sepenuhnya. Apakah jenis kegagalan yang anda sediakan dan boleh tangani?
Jika kita bercakap tentang pemasangan gugusan Cassandra kami, pengguna tidak akan menyedari apa-apa jika kami kehilangan beberapa mesin dalam satu DC atau satu keseluruhan DC (ini telah berlaku). Dengan pertambahan bilangan DC, kami sedang memikirkan untuk mula memastikan kebolehkendalian sekiranya berlaku kegagalan dua DC.
β Pada pendapat anda, apakah kekurangan Cassandra dari segi toleransi kesalahan?
Cassandra, seperti banyak kedai NoSQL awal yang lain, memerlukan pemahaman mendalam tentang struktur dalamannya dan proses dinamik yang berlaku. Saya akan mengatakan bahawa ia tidak mempunyai kesederhanaan, kebolehramalan dan kebolehmerhatian. Tetapi ia akan menjadi menarik untuk mendengar pendapat peserta mesyuarat lain!
Oleg, terima kasih banyak kerana meluangkan masa untuk menjawab soalan!
Kami sedang menunggu semua orang yang ingin berkomunikasi dengan pakar dalam bidang pengendalian Apache Cassandra pada pertemuan pada 12 September di pejabat St. Petersburg kami.
Datang, ia akan menjadi menarik!
Sumber: www.habr.com