Get best of the week

Tentang cluster server 1C

Cluster adalah jenis sistem paralel
atau terdistribusi yang:
1. terdiri dari beberapa
komputer yang saling berhubungan ;
2. Digunakan sebagai
sumber daya komputer tunggal, terpadu

Gregory F. Pfister, “Mencari kluster”.

Mengingat: ada aplikasi bisnis (misalnya, sistem ERP) yang dengannya ribuan (mungkin puluhan ribu) pengguna bekerja secara bersamaan.

Diperlukan:
  1. Buat aplikasi scalable, sehingga dengan peningkatan jumlah pengguna, dimungkinkan karena peningkatan sumber daya perangkat keras untuk memberikan kinerja aplikasi yang diperlukan.
  2. Buat aplikasi tahan terhadap kegagalan komponen sistem (baik perangkat lunak dan perangkat keras), kehilangan koneksi antara komponen dan masalah lain yang mungkin terjadi.
  3. Gunakan sumber daya sistem seefisien mungkin dan berikan kinerja aplikasi yang diinginkan.
  4. Buat sistem mudah digunakan dan dikelola.

Untuk mengatasi masalah ini, kami menggunakan arsitektur cluster di platform 1C: Enterprise.

Kami tidak segera mencapai hasil yang diinginkan.

Pada artikel ini, kita akan berbicara tentang apa itu cluster, bagaimana kita memilih tipe cluster yang sesuai dengan kita dan bagaimana cluster kita berevolusi dari versi ke versi, dan pendekatan mana yang memungkinkan kita untuk akhirnya menciptakan sistem yang melayani puluhan ribu pengguna simultan.

gambar

Seperti Gregory Pfister, penulis epigraf untuk artikel ini, menulis dalam bukunya "Mencari cluster," cluster tidak ditemukan oleh produsen perangkat keras atau perangkat lunak tertentu, tetapi oleh pelanggan yang tidak memiliki kekuatan satu komputer atau perlu redundansi. Ini terjadi, menurut Pfister, di tahun 60-an abad lalu.
Secara tradisional membedakan jenis-jenis utama klaster berikut:

  1. Cluster Failover (HA, Cluster Ketersediaan Tinggi)
  2. Cluster load balancing (LBC)
  3. Cluster komputasi (Cluster komputasi kinerja tinggi, HPC)
  4. (grid) , . grid- , . grid- HPC-, .

Untuk mengatasi masalah kami (ketahanan terhadap kegagalan komponen sistem dan penggunaan sumber daya yang efisien), kami perlu menggabungkan fungsionalitas kluster gagal-aman dan kluster dengan penyeimbangan beban. Kami tidak langsung mengambil keputusan ini, tetapi melakukan pendekatan secara evolusioner, langkah demi langkah.

Bagi mereka yang tidak up to date, saya akan memberi tahu Anda secara singkat bagaimana aplikasi bisnis 1C diatur. Ini adalah aplikasi yang ditulis dalam bahasa yang berorientasi pada subjek , "diasah" untuk otomatisasi tugas-tugas bisnis akuntansi. Untuk menjalankan aplikasi yang ditulis dalam bahasa ini, 1C: runtime platform perusahaan harus diinstal pada komputer.

1C: Perusahaan 8.0


Versi pertama dari server aplikasi 1C (belum cluster) muncul di platform versi 8.0. Sebelum itu, 1C bekerja di versi client-server, data disimpan dalam file DBMS atau MS SQL, dan logika bisnis bekerja secara eksklusif pada klien. Dalam versi 8.0, transisi dibuat ke arsitektur tiga-tier "client - application server - DBMS".

Server 1C pada platform 8.0 adalah COM +server yang dapat menjalankan kode aplikasi dalam 1C. Menggunakan COM + memberi kami transportasi siap pakai, memungkinkan aplikasi klien untuk berkomunikasi dengan server melalui jaringan. Banyak hal dalam arsitektur interaksi klien-server dan objek aplikasi yang tersedia untuk pengembang 1C dirancang dengan mempertimbangkan penggunaan COM +. Pada saat itu, toleransi kesalahan tidak dibangun ke dalam arsitektur, dan server crash menyebabkan semua klien ditutup. Ketika aplikasi server macet, COM + mengangkatnya ketika klien pertama mengaksesnya, dan klien memulai pekerjaan mereka dari awal - dari koneksi ke server. Pada saat itu, semua pelanggan dilayani oleh satu proses.
gambar

1C: Perusahaan 8.1


Dalam versi berikutnya, kami ingin:

  • Berikan toleransi kesalahan kepada pelanggan kami sehingga kecelakaan dan kesalahan beberapa pengguna tidak mengarah pada kecelakaan dan kesalahan pengguna lain.
  • Singkirkan teknologi COM +. COM + hanya berfungsi di Windows, dan pada saat itu kemungkinan bekerja di Linux sudah menjadi relevan.

Pada saat yang sama, kami tidak ingin mengembangkan versi baru platform dari awal - itu akan terlalu banyak sumber daya. Kami ingin memanfaatkan pencapaian kami secara maksimal, serta menjaga kompatibilitas dengan aplikasi yang dikembangkan untuk versi 8.0.

Jadi di versi 8.1 cluster pertama muncul. Kami menerapkan protokol kami untuk panggilan prosedur jarak jauh (di atas TCP), yang dalam penampilannya tampak hampir seperti COM + untuk konsumen-klien akhir (mis., Kami praktis tidak harus menulis ulang kode yang bertanggung jawab untuk panggilan klien-server). Pada saat yang sama, kami membuat server diimplementasikan dalam platform C ++ independen, mampu bekerja pada Windows dan Linux.

Server versi monolitik 8.0 digantikan oleh 3 jenis proses - proses kerja yang melayani klien, dan 2 proses layanan yang mendukung operasi cluster:

  • rphost adalah alur kerja yang melayani pelanggan dan menjalankan kode aplikasi. Cluster dapat memiliki lebih dari satu alur kerja, alur kerja yang berbeda dapat dieksekusi pada server fisik yang berbeda - karena skalabilitas ini tercapai.
  • ragent - proses agen server yang memulai semua jenis proses lainnya, serta daftar utama cluster yang terletak di server ini.
  • rmngr adalah manajer kluster yang mengontrol operasi seluruh kluster (tetapi kode aplikasi tidak berfungsi di dalamnya).

Di bawah cut adalah diagram operasi dari ketiga proses dalam cluster.
image

Selama sesi, klien bekerja dengan satu alur kerja, penurunan alur kerja dimaksudkan untuk semua klien yang dilayani proses ini, sesi diakhiri secara tidak normal. Pelanggan yang tersisa terus bekerja.
gambar

1C: Perusahaan 8.2


Dalam versi 8.2, kami ingin aplikasi 1C dapat berjalan tidak hanya di klien asli (yang dapat dieksekusi), tetapi juga di browser (tanpa mengubah kode aplikasi). Dalam hal ini, khususnya, tugas muncul dari decoupling keadaan aplikasi saat ini dari koneksi saat ini dengan alur kerja rphost dan membuatnya stateless. Akibatnya, konsep sesi dan data sesi muncul yang harus disimpan di luar alur kerja (karena itu stateless). Layanan data sesi telah dikembangkan yang menyimpan dan menyimpan informasi sesi. Layanan lain juga muncul - layanan kunci transaksional terkelola, layanan pencarian teks lengkap, dll.

Versi ini juga memperkenalkan beberapa inovasi penting - peningkatan toleransi kesalahan, penyeimbangan muatan, dan mekanisme redundansi kluster.

toleransi kesalahan


Karena proses kerja menjadi stateless dan semua data yang diperlukan untuk pekerjaan disimpan di luar klien saat ini - koneksi alur kerja, dalam hal terjadi kecelakaan alur kerja, klien beralih ke yang lain, alur kerja "langsung" saat berikutnya mengakses server. Dalam kebanyakan kasus, saklar semacam itu tidak terlihat oleh klien.

Mekanismenya bekerja seperti ini. Jika panggilan klien ke alur kerja karena alasan tertentu tidak dapat diselesaikan sampai akhir, maka bagian klien dapat, setelah menerima kesalahan panggilan, ulangi panggilan ini dengan membangun kembali koneksi ke alur kerja yang sama atau ke yang lain. Tetapi Anda tidak selalu dapat mengulangi panggilan; Ulangi panggilan berarti bahwa kami mengirim panggilan ke server, tetapi tidak menerima hasilnya. Kami mencoba mengulangi panggilan, saat melakukan panggilan kedua, kami mengevaluasi apa hasil dari panggilan sebelumnya di server (informasi tentang ini disimpan di server dalam data sesi), karena jika panggilan punya waktu untuk "mewarisi" di sana (menutup transaksi, simpan data sesi dll.) - tidak mungkin untuk mengulanginya, itu akan menyebabkan ketidakkonsistenan data. Jika panggilan tidak dapat diulang, klien akan menerima pesan tentang kesalahan yang tidak dapat dipulihkan,dan aplikasi klien harus memulai ulang. Jika Anda tidak berhasil "mewarisi" panggilan (dan ini adalah situasi yang paling umum, karena banyak panggilan tidak mengubah data, misalnya, melaporkan, menampilkan data pada formulir, dll., Dan mereka yang mengubah data tidak memiliki transaksi atau sampai perubahan dalam data sesi telah dikirim ke manajer - tidak ada jejak panggilan) - itu dapat diulang tanpa risiko inkonsistensi data. Jika alur kerja macet atau koneksi jaringan terputus, panggilan seperti itu diulangi, dan ini "bencana" untuk aplikasi klien terjadi sepenuhnya tanpa disadari.bahwa perubahan data - sampai transaksi dilakukan atau sampai perubahan data sesi dikirim ke manajer - tidak ada jejak panggilan) - hal itu dapat diulang tanpa risiko ketidakkonsistenan data. Jika alur kerja macet atau koneksi jaringan terputus, panggilan seperti itu diulangi, dan ini "bencana" untuk aplikasi klien terjadi sepenuhnya tanpa disadari.bahwa perubahan data - sampai transaksi dilakukan atau sampai perubahan data sesi dikirim ke manajer - tidak ada jejak panggilan) - hal itu dapat diulang tanpa risiko ketidakkonsistenan data. Jika alur kerja macet atau koneksi jaringan terputus, panggilan seperti itu diulangi, dan ini "bencana" untuk aplikasi klien terjadi sepenuhnya tanpa disadari.

Penyeimbang beban


Tugas load balancing dalam kasus kami adalah sebagai berikut: klien baru memasuki sistem (atau klien yang sudah bekerja membuat panggilan lain). Kita harus memilih server dan alur kerja mana untuk mengirim panggilan klien untuk memberikan kecepatan maksimum kepada klien.

Ini adalah tugas standar untuk kluster yang seimbang beban. Ada beberapa algoritma khas untuk menyelesaikannya, misalnya:


Untuk kluster kami, kami memilih algoritma yang pada dasarnya dekat dengan Least Response Time. Kami memiliki mekanisme yang mengumpulkan statistik tentang kinerja alur kerja di semua server di kluster. Itu membuat panggilan referensi untuk setiap proses server di cluster; panggilan referensi melibatkan subset fungsi dari subsistem disk, memori, prosesor, dan mengevaluasi seberapa cepat panggilan tersebut dibuat. Hasil dari pengukuran ini, rata-rata selama 10 menit terakhir, adalah kriteria - dimana server dalam cluster adalah yang paling produktif dan disukai untuk mengirim koneksi klien ke sana dalam periode waktu tertentu. Permintaan klien didistribusikan sedemikian rupa agar lebih baik memuat server paling produktif - muat orang yang beruntung.

Permintaan dari klien baru ditujukan ke server paling produktif saat ini.

Permintaan dari klien yang ada dalam banyak kasus ditujukan ke server itu dan ke alur kerja yang permintaan sebelumnya ditangani. Seperangkat data yang luas di server dikaitkan dengan klien yang bekerja, mentransfernya di antara proses (dan bahkan lebih lagi di antara server) cukup mahal (meskipun kita juga bisa melakukan ini).

Permintaan dari klien yang ada ditransfer ke alur kerja lain dalam dua kasus:

  1. Tidak ada lagi proses: alur kerja yang sebelumnya berinteraksi dengan klien tidak lagi tersedia (proses telah jatuh, server menjadi tidak tersedia, dll.).
  2. : , , , , . , , – . – (.. ).



Kami memutuskan untuk meningkatkan ketahanan cluster dengan beralih ke skema Aktif / pasif . Ada kesempatan untuk mengkonfigurasi dua cluster - bekerja dan cadangan. Jika cluster utama tidak tersedia (masalah jaringan atau, misalnya, pemeliharaan terjadwal), panggilan klien dialihkan ke cluster cadangan.

Namun, desain ini cukup sulit untuk dikonfigurasi. Administrator harus secara manual merakit dua grup server menjadi cluster dan mengkonfigurasinya. Terkadang administrator membuat kesalahan dengan menetapkan pengaturan yang saling bertentangan, seperti tidak ada mekanisme terpusat untuk memeriksa pengaturan. Namun, bagaimanapun, pendekatan ini meningkatkan toleransi kesalahan sistem.
gambar

1C: Perusahaan 8.3


Dalam versi 8.3, kami secara substansial menulis ulang kode sisi server yang bertanggung jawab untuk toleransi kesalahan. Kami memutuskan untuk meninggalkan skema kluster Aktif / pasif karena kerumitan konfigurasinya. Hanya satu cluster toleran-kesalahan yang tersisa dalam sistem, yang terdiri dari sejumlah server - ini lebih dekat dengan skema Aktif / aktif di mana permintaan untuk simpul yang gagal didistribusikan di antara simpul-simpul kerja yang tersisa. Karena ini, kluster menjadi lebih mudah untuk dikonfigurasi. Sejumlah operasi yang meningkatkan toleransi kesalahan dan meningkatkan penyeimbangan muatan telah menjadi otomatis. Dari inovasi penting:

  • « »: , , . , «» .
  • , , .
  • , , , , , :

gambar

gambar

Gagasan utama dari perkembangan ini adalah untuk menyederhanakan pekerjaan administrator, memungkinkannya untuk mengkonfigurasi cluster dalam istilah yang akrab dengannya, pada tingkat operasi server, tidak turun lebih rendah, dan juga untuk meminimalkan tingkat "kontrol manual" dari pekerjaan cluster, memberikan mekanisme cluster untuk menyelesaikan sebagian besar tugas kerja dan kemungkinan masalah " dengan autopilot. "

gambar

Tiga tautan toleransi kesalahan


Seperti yang Anda ketahui, bahkan jika komponen sistem secara terpisah dapat diandalkan, masalah dapat timbul di mana komponen sistem menyebabkan satu sama lain. Kami ingin meminimalkan jumlah tempat penting untuk kinerja sistem. Pertimbangan tambahan yang penting adalah minimalisasi perubahan mekanisme yang diterapkan dalam platform dan pengecualian perubahan dalam solusi yang diterapkan. Dalam versi 8.3, ada 3 tautan untuk memastikan toleransi kesalahan “pada sambungan”:

gambar
  1. , HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
  2. , .
  3. - . 1, - . - . , . , – . - (, , , ) – .
  4. , rmngr. 20 ( ) — , .. . 1: .



Berkat mekanisme toleransi kesalahan, aplikasi yang dibuat pada 1C: Platform perusahaan berhasil bertahan dari berbagai jenis kegagalan server produksi di cluster, sementara sebagian besar klien terus bekerja tanpa memulai ulang.

Ada situasi ketika kita tidak dapat mengulangi panggilan, atau server crash menangkap platform pada titik waktu yang sangat disayangkan, misalnya, di tengah transaksi dan tidak begitu jelas apa yang harus dilakukan dengan mereka. Kami mencoba untuk memastikan kelangsungan hidup klien yang baik secara statistik ketika server jatuh dalam gugus. Sebagai aturan, kehilangan rata-rata klien untuk kegagalan server adalah beberapa persen. Dalam hal ini, semua klien "hilang" dapat terus bekerja di cluster setelah memulai kembali aplikasi klien.

Keandalan cluster server 1C dalam versi 8.3 telah meningkat secara signifikan. Sudah lama tidak jarang untuk memperkenalkan produk 1C, di mana jumlah pengguna yang bekerja secara bersamaan mencapai beberapa ribu. Ada implementasi di mana 5.000 dan 10.000 pengguna bekerja secara bersamaan - misalnya, pengantar di Beeline , di mana 1C: aplikasi Trade Management melayani semua outlet penjualan Beeline di Rusia, atau penerapan Business Lines di pengangkutan barang , di mana aplikasinya, dibuat secara independen oleh pengembang departemen TI Lines Bisnis pada platform 1C: Enterprise, melayani siklus penuh transportasi kargo. Tes beban kluster internal kami mensimulasikan operasi simultan hingga 20.000 pengguna.

Sebagai kesimpulan, saya ingin mendaftar secara singkat apa lagi yang berguna di cluster kami (daftar tidak lengkap):

  • , . , , .
  • – , , , ( – , ..) . , , (, ) , ERP, , ERP.
  • – , (, , ..). , , , , , .

More articles:


All Articles