Halo semuanya! Setiap hari, tim teknisi kami yang besar dan ramah memecahkan masalah kompleks dan berkontribusi pada pembuatan produk berteknologi tinggi - pemrosesan data dan sistem penyimpanan. Kami memutuskan untuk memperkenalkan Anda pada rutinitas mereka lebih dekat, dan hari ini kami memulai serangkaian wawancara dengan rekan kerja untuk memberi tahu Anda tentang semua nuansa pekerjaan mereka secara langsung.
Kinerja adalah salah satu karakteristik utama dari perangkat lunak yang baik; karakteristik lain dari sistem penyimpanan tidak akan dihargai jika lambat atau tidak stabil. Hari ini kita berbicara dengan Sergey Kachkin
kachini- Kepala Departemen Keahlian Teknis Departemen Riset Terapan dan Keahlian Teknis di YADRO.
Profesinya memiliki beberapa nama: analis kinerja, insinyur kinerja, penguji kinerja. Dan semuanya cukup langka di Rusia. Sementara itu, rekayasa kinerja membantu menciptakan sistem komputer yang efisien yang beroperasi dengan cepat dan andal. Tugasnya adalah mempelajari mengapa sistem tidak berfungsi seperti yang kita inginkan, memahami alasan lambatnya operasi atau tidak sesuai dengan parameter target, mengidentifikasi dan menemukan area masalah, dan membantu menghilangkannya.
Sergey Kachkin berbicara tentang menemukan kemacetan dalam tumpukan perangkat lunak dan mengoptimalkan kinerja penyimpanan, tentang apa yang dilakukan timnya.
Sergey, bagaimana Anda bisa datang ke YADRO? Apakah Anda sudah memiliki pengalaman dengan OpenPOWER?
Sebelumnya, saya bekerja untuk vendor lain, terlibat dalam mendukung versi eksklusif UNIX OS pada prosesor IA64 (jangan disamakan dengan x86) dalam hal kinerja kernel. Arsitektur EPIC tidak seperti RISC, ia sangat berbeda. Jadi ini adalah pengalaman pertama saya bekerja dengan OpenPOWER di YADRO, dan pembangunannya kembali memakan waktu. Tapi ide OpenPOWER, meski ada beberapa minimalis, adalah sama, jadi semuanya bisa dikuasai.
Apa yang dilakukan insinyur kinerja? Metode apa yang digunakan dalam pekerjaan? Apakah Anda sulit merekrut karyawan baru?
Spesialisasi utama tim kami adalah rekayasa kinerja atau rekayasa kinerja. Ini adalah disiplin terpisah yang bertujuan untuk memastikan bahwa solusi yang dikembangkan memenuhi persyaratan non-fungsional, khususnya, kinerja. Ini mencakup seperangkat praktik, pengetahuan, metode dan teknik yang dapat diterapkan pada berbagai tahap pengembangan perangkat lunak: persiapan, pemrograman, pengujian, dan operasi sistem.
Di Rusia, disiplin ini tidak terlalu meluas, setidaknya kesan seperti itu tercipta dari hasil pencarian karyawan. Namun, di dunia, ini adalah arah yang mapan. Spesialisasi TI ini jarang melibatkan pengkodean langsung. Kami sedikit memprogram dan, pada kenyataannya, tidak tahu bagaimana melakukannya seperti pemrogram profesional. Ini membutuhkan keterampilan khusus untuk melokalkan "hot spot" di perangkat lunak yang memengaruhi persyaratan non-fungsional. Di satu sisi, ini membantu untuk membuat produk yang memenuhi persyaratan, di sisi lain, ini mencegah biaya pengoptimalan atau pengerjaan ulang lebih lanjut.
Bagaimana Anda memastikan kontrol kualitas dan identifikasi hambatan dalam tumpukan perangkat lunak?
Metode dapat dibagi menjadi dua jenis. Yang pertama adalah pendekatan sistem sentris. Berorientasi pada sumber daya: kami menganalisis beban masing-masing komponen sistem dan, berdasarkan hasil yang diperoleh, membuat asumsi jika terdapat kemacetan.
Kedua adalah application centric approach, dimana objek penelitiannya adalah seluruh aplikasi atau proses individual di Linux. Kami melihat apa yang dilakukan aplikasi, pekerjaan apa yang dilakukannya. Apakah pekerjaan ini bermanfaat, atau melakukan sesuatu yang tidak berguna, yaitu membuang-buang waktu. Jika aplikasi sedang menunggu, kami melihat apa yang ditunggu. Biasanya ini adalah sumber daya perangkat keras atau perangkat lunak, mekanisme sinkronisasi.
Dalam kehidupan nyata, Anda harus beralih di antara metode ini. Artinya, di satu sisi, kami melihat sumber daya: apakah ada masalah yang jelas, kesalahan. Kami menarik kesimpulan. Lalu kita lihat aplikasinya: bagaimana rasanya. Dalam hal ini, aplikasi adalah kode sistem penyimpanan atau hal lain yang menjadi objek pengoptimalan.
Bagaimana memahami bahwa penyimpanan bekerja "pada batas"? Bagaimana Anda bisa tahu jika produktivitas Anda habis? Parameter apa yang menunjukkan ini? Apa metrik utama yang digunakan untuk mengukur kinerja penyimpanan?
Beberapa metrik tersedia untuk pengguna rata-rata. Yang utama adalah waktu respons. Nilai absolutnya penting. Selain waktu respon, bandwidth juga penting. Jika, seiring bertambahnya beban, waktu respons mulai bertambah, sedangkan IOPS dan jumlah data yang ditransmisikan tidak meningkat, ini berarti bahwa beberapa sumber daya penyimpanan mendekati saturasi. Seperti yang Anda ketahui, sistem penyimpanan bekerja secepat sumber daya yang paling lambat dapat berfungsi.
Pada saat yang sama, aplikasi yang berbeda dapat menjadi sangat penting untuk waktu respons atau bandwidth. Misalnya, jika kita berbicara tentang database, maka biasanya itu adalah akses acak di blok kecil, banyak pembacaan, dan penting untuk melakukannya di IOPS dan waktu respons minimum. Untuk beban lain seperti streaming untuk backup, merekam dari kamera video atau Internet of Things, bandwidth lebih penting, kemampuan untuk merekam aliran data yang besar.
Apakah sistem penyimpanan dioptimalkan untuk tugas tertentu, atau dibuat sebagai solusi universal?
Untuk waktu yang lama, sistem penyimpanan, setidaknya untuk tujuan umum, bersifat serbaguna. Mereka tidak "diasah" untuk beban tertentu dan mencoba untuk "menyenangkan" aplikasi yang paling umum. Lagi pula, secara kasar diketahui apa yang memuat profil database, sistem backup, video surveillance, dan sebagainya. Sistem penyimpanan harus merespons beban tersebut secara memadai tanpa konfigurasi tambahan apa pun.
Oleh karena itu, sistem penyimpanan serba guna dirancang dari awal agar sesuai dengan tugas yang paling umum. Untuk ini, pengujian sintetis digunakan dengan sekumpulan profil "kritis" yang mensimulasikan situasi nyata. Seringkali itu berhasil, tetapi kenyataannya selalu jauh lebih rumit.
Beban nyata dimodelkan oleh sintetis dengan sangat mendekati. Ini umumnya merupakan bidang sains yang intensif, karena selain IOPS, bandwidth, ukuran blok, dan rasio operasi baca / tulis, beban memiliki lebih banyak karakteristik. Ini adalah lokalisasi tempat data pada disk, keberadaan "area panas", distribusi permintaan dalam waktu, dan keseragaman kedatangan mereka. Oleh karena itu, ada kemungkinan bahwa beban tertentu k tidak akan jatuh ke salah satu profil. Mungkin karena fitur perangkat lunak atau spesifikasi dari tugas bisnis itu sendiri. Dalam kasus ini, Anda perlu mengkonfigurasi sistem untuk tugas tertentu.
Periksa aplikasi, cara kerjanya. Dan mungkin perlu untuk mengubah pengoperasian aplikasi atau pengaturan penyimpanan. Terkadang jauh lebih mudah untuk menyelesaikan masalah di sisi aplikasi dengan beberapa jenis penyesuaian daripada mengubah sistem penyimpanan.
Apakah sistem secara otomatis dikonfigurasi untuk tugas tersebut? Apakah Anda memerlukan kecerdasan buatan untuk ini? Dapatkah administrator atau pengguna memilih sendiri profil pemuatan?
Sistem penyimpanan telah melakukan ini secara otomatis untuk waktu yang lama - administrator tidak dimuati dengan tugas seperti itu. Biasanya mereka mencoba untuk mencapai ini tanpa menggunakan kecerdasan buatan - algoritma tradisional. Namun, AI memiliki potensi yang besar. Jika memungkinkan Anda untuk memprediksi blok data mana dan pada titik waktu mana aplikasi dapat meminta, maka Anda dapat mempersiapkannya terlebih dahulu.
Jika algoritme pengoptimalan sebelumnya cukup sederhana, seperti read-ahead, yaitu, saat membaca data secara berurutan, sistem memuat data ke dalam cache terlebih dahulu, atau, sebaliknya, membebaskan memori cache untuk data lain, sekarang kemungkinannya meluas: sistem akan dapat mempersiapkan puncak permintaan atau terorganisir secara kompleks " hot data spot ".
Berapa skala pengoptimalan penyimpanan? Apakah itu juga mencakup perangkat lunak / perangkat keras server, infrastruktur (SAN)? Apakah itu memerlukan integrasi yang erat dari tumpukan perangkat lunak dan perangkat keras?
Dari sudut pandang rekayasa kinerja, sistem dianggap secara keseluruhan, dalam kompleks, yaitu, aplikasi, host (server), infrastruktur penyimpanan, (SAN), sistem penyimpanan. Penting untuk memahami cara kerja aplikasi, karena aplikasi itulah yang menghasilkan permintaan ke sistem penyimpanan. Semua ini, tentu saja, diperhitungkan dan digunakan.
Diyakini bahwa opsi paling optimal untuk menggunakan drive dari berbagai jenis dalam sistem penyimpanan adalah penyimpanan data berjenjang. Bisakah merobek dianggap sebagai cara untuk meningkatkan kinerja penyimpanan?
Secara umum, merobek mirip dengan cache - mereka memiliki elemen yang sama. Satu-satunya perbedaan adalah bahwa ketika caching, data digandakan, yaitu terletak di SSD (di cache) dan di disk, dan ketika tiering disimpan hanya di satu tempat. Artinya, jika caching adalah cara untuk mengoptimalkan kinerja, maka merobek juga dapat dianggap sebagai metode pengoptimalan.
Di mana Anda melihat keuntungan / kerugian dari penyimpanan yang ditentukan perangkat lunak (SDS) dalam hal analisis kinerja dan pengoptimalan sistem? Mungkin ini adalah solusi yang lebih sederhana dan lebih fleksibel?
Faktanya, justru sebaliknya. SDS adalah sistem terdistribusi yang terdiri dari banyak server yang berinteraksi satu sama lain. Jika sistem operasi khusus digunakan, beberapa jenis sistem file, maka ini juga menambah kerumitan. Dari sudut pandang teknik, ini lebih sulit, tetapi dalam beberapa hal lebih menarik. Di sisi lain, SDS biasanya tidak memiliki persyaratan kinerja yang ketat, sementara sistem penyimpanan klasik lebih ketat. Apa yang dimaafkan untuk sistem yang ditentukan perangkat lunak tidak akan dimaafkan untuk penyimpanan tradisional.
Salah satu tujuan perusahaan adalah mengembangkan produk yang dioptimalkan untuk kecerdasan buatan, IoT, dan jaringan generasi kelima. Seberapa sulit menurut Anda ini? Akan seperti apa produk ini?
Saat ini, penyimpanan file sering digunakan untuk menyimpan data mentah dalam AI, dan SDS digunakan untuk melatih dan membangun model, yang hampir selalu merupakan solusi terdistribusi. Menurut saya, banyak perusahaan sekarang menggunakan AI sebagai semacam eksperimen, mereka melihatnya dan mencoba memahami bagaimana hal itu bisa berguna. Oleh karena itu, persyaratan perangkat keras tidak terlalu ketat. Jika berhasil - ya, tidak berhasil - Anda bisa menunggu satu atau dua hari. Karena pekerjaan AI di perusahaan menjadi lebih penting, begitu pula persyaratan untuk subsistem disk. Kami akan melihat solusi penyimpanan baru untuk AI dan Internet of Things sudah kelas kritis misi.
Peran apa yang dimainkan oleh kemitraan YADRO dengan perusahaan teknologi global dalam pengoptimalan perangkat lunak?
Dari sudut pandang teknisi, ini pasti membantu. Kerja sama seperti itu memfasilitasi komunikasi para insinyur satu sama lain, akses mereka ke informasi, pengembangan yang siap pakai, dan tidak harus "menemukan kembali roda" setiap saat.
Bagaimana Anda melihat peran virtualisasi dalam penyimpanan? Apakah itu membantu menghilangkan kemacetan perangkat lunak, atau sebaliknya? Dan bagaimana kinerja dan keandalan sistem terkait? Dapatkah keandalan dipertahankan sekaligus meningkatkan produktivitas?
Virtualisasi menambah kerumitan, tentu saja, tetapi dapat berguna untuk mengisolasi satu fungsionalitas penyimpanan dari yang lain. Secara umum, ini adalah biaya tambahan dan komplikasi, jadi ini harus dilihat secara kritis, dengan hati-hati.
Dalam hal meningkatkan produktivitas, memang mudah kehilangan keandalan dalam prosesnya. Ini semacam dualisme. Misalnya, ketika kita berbicara tentang server, untuk server berkinerja tinggi (HPC), keandalan biasanya didahulukan. Sistem penyimpanan biasanya perlu menyediakan ketersediaan, fungsionalitas, dan kinerja yang tinggi terlebih dahulu. Dengan meningkatnya keandalan tingkat redundansi, sistem menjadi lebih kompleks. Menjadi perlu untuk menyinkronkan elemen. Namun, performa sistem pasti akan terganggu. Tugas pembangunan adalah meminimalkan efek ini.
Sekarang ada kelas memori baru seperti Storage Class Memory, Persistent Memory, flash drive sedang ditingkatkan. Bagaimana hal ini mempengaruhi arsitektur sistem? Apakah perangkat lunak mengikuti perubahan ini?
Yah, setidaknya dia mencoba. Secara umum, munculnya memori cepat telah mengubah secara signifikan cara kerja insinyur kinerja di industri. Sebelum munculnya SSD, sebagian besar masalah kinerja TI terkait dengan I / O penyimpanan. Karena ada prosesor dan disk (HDD) cepat dengan elemen mekanis yang banyak lipatnya lebih lambat dari prosesor. Oleh karena itu, dengan mengorbankan algoritme, kami harus mencoba memuluskan penundaan dari disk yang lambat.
Dengan munculnya memori yang cepat dan algoritma harus berubah. Jika algoritme cukup berat, masih membantu sebelumnya, karena disk jauh lebih lambat. Jika Anda berhasil menyembunyikan keterlambatan mekanik, itu bagus. Dengan munculnya SSD, perangkat lunak harus bekerja secara berbeda. Ini harus memperkenalkan latensi minimum untuk mendapatkan kecepatan maksimum dari SSD. Artinya, kebutuhan akan algoritme kompleks yang menyembunyikan latensi dari disk telah berkurang. Database intensif I / O yang sangat sensitif terhadap waktu respons dapat dimigrasi ke SSD.
Apakah ini akan mengubah arsitektur penyimpanan? Iya dan tidak. Karena disk tidak kemana-mana. Di satu sisi, kode harus dapat bekerja dengan SSD, yaitu, sangat cepat. Di sisi lain, cakram mekanis menggunakan beban yang dapat ditahan dengan baik, seperti streaming. Pada saat yang sama, ukuran disk telah berkembang berkali-kali lipat, tetapi kecepatannya tetap sama seperti 10 tahun yang lalu.