Pertanyaan Bagaimana saya bisa menggunakan Apache untuk memuat keseimbangan Marklogic Cluster


Hai, saya baru di Marklogic dan Apache. Saya telah diberikan tugas untuk menggunakan apache sebagai loadbalancer untuk cluster Marklogic kami dari 3 mesin. Cluster marklogic saat ini berjalan di server Linux.

Bagaimana kita bisa mencapai hal ini? Setiap informasi mengenai ini akan sangat membantu.


5
2018-06-17 13:30


asal


Jawaban:


Anda bisa menggunakannya mod_proxy_balancer. Cara Anda mengonfigurasinya bergantung pada klien MarkLogic yang ingin Anda gunakan. Jika Anda ingin menggunakan API Klien Java, silakan ikuti contoh kedua sini untuk memungkinkan apache menghasilkan cookie lengket. Jika Anda ingin menggunakan XCC, konfigurasikan untuk menggunakan ML-Server-generated atau backend-generated Cookie "SessionID".

Perbedaannya di sini adalah bahwa XCC menggunakan sesi sedangkan API Klien Java dibangun di API REST yang tidak memiliki negara, sehingga tidak ada sesi. Namun, bahkan di API Klien Java ketika Anda menggunakan transaksi multi-permintaan, yang memberlakukan status untuk durasi transaksi tersebut sehingga penyeimbang beban memerlukan cara untuk merutekan permintaan selama transaksi tersebut ke node yang benar dalam gugus MarkLogic. Cookie kelengketan akan dikirim ulang oleh API Klien Java dengan setiap permintaan yang menggunakan Transaksi sehingga load balancer dapat mempertahankan kelengketan tersebut untuk permintaan yang terkait dengan transaksi tersebut.

Seperti biasa, lakukan beberapa pengujian konfigurasi Anda untuk memastikan Anda melakukannya dengan benar. Mengkonfigurasi plugin apache dengan benar adalah keterampilan tingkat lanjut. Karena Anda baru mengenal Apache, harapan terbaik Anda untuk memastikan Anda melakukannya dengan benar adalah memeriksa dengan alat pemantau HTTP seperti WireShark untuk melihat lalu lintas HTTP dari aplikasi Anda ke MarkLogic Server untuk memastikan semuanya berjalan ke node yang benar di kluster seperti yang diharapkan.


7
2018-06-17 19:12



Perhatikan bahwa bahkan dengan API klien (Java, Node.js) tidak selalu jelas atau eksplisit pada lapisan API bahasa apa yang mungkin menyebabkan sesi dibuat. Secara eksplisit membuat transaksi multi-statement pasti akan, tetapi operasi lain dapat melakukannya juga. Jika Anda menggunakan koneksi yang sama untuk UI (browser) dan API (REST atau XCC), maka aplikasi browser kemungkinan akan melakukan hal-hal yang menciptakan status sesi.

Konfigurasi paling aman, tetapi paling tidak fleksibel adalah "Sesi TCP Affinity". Jika didukung mereka akan menghilangkan sebagian besar kekhawatiran terkait dengan load balancing. Afinitas Sesi Cookie bergantung pada jaminan bahwa load balencer menggunakan cookie yang benar. Tidak semua kode sama. Saya memiliki kasus di mana penyeimbang beban tidak selalu menggunakan cookie yang disediakan. Mengubah konfigurasi ke "Load Balancer disediakan Cookie Affinity" memperbaikinya.

Semua ini tidak diperlukan jika semua komunikasi Anda tidak memiliki negara di lapisan TCP, lapisan HTTP, dan lapisan aplikasi. Nantinya tidak dapat disimpulkan oleh server. Masalah lain adalah jika aplikasi atau tier menengah Anda adalah co-residen dengan aplikasi lain atau aplikasi yang sama terhubung ke load balancer dan port yang sama. Itu bisa sulit untuk memastikan tidak ada 'kabel silang'. Ketika ML mendapat permintaan itu mengaitkan identitasnya dengan IP dan port klien. Bahkan tanpa load balencers, kebanyakan pustaka klien HTTP dan TCP modern menerapkan cache soket. Kemenangan perfomrance yang hebat, tetapi sumber tersembunyi dari kesalahan acak yang parah jika perpustakaan atau aplikasi berbagi "guci kue" (bukan uncomnon). Cache TCP dan Cookie Jar yang digunakan oleh konteks aplikasi yang berbeda dapat menyebabkan pengiriman informasi negara dari satu aplikasi yang tidak terkait dalam proses yang sama ke yang lain. Sebagian besar ini berada di server aplikasi tingkat menengah yang mungkin hanya meneruskan permintaan dari tier pertama tanpa pengetahuan domain, menganggap bahwa bergantung pada pustaka TCP tingkat rendah untuk "melakukan hal yang benar" ... Mereka melakukan hal yang benar - karena use case programmer perpustakaan yang ada dalam pikiran - jangan berasumsi bahwa kasus Anda adalah yang diasumsikan oleh penulis perpustakaan. Gejala-gejalanya cenderung sangat jarang tetapi masalah-masalah bencana dengan kegagalan transaksi dan mungkin data korupsi dan masalah keamanan (pada lapisan aplikasi) karena server tidak dapat membedakan antara 2 koneksi dari tingkat tengah yang sama.

Terkadang strategi yang lebih baik adalah memuat keseimbangan antara tier pertama dan tier tengah, dan langsung menghubungkan dari tier tengah ke MarkLogic. Terutama jika caching dilakukan pada load balancer. Yang lebih umum untuk caching menjadi berguna antara tingkat menengah dan klien maka tingkat menengah dan server. Ini juga lebih analog dengan arsitektur 3 tier klasik yang digunakan dengan RDBMS's .. di mana load balancing adalah antara klien dan tingkatan logika bisnis tidak antara logika bisnis dan database.


1
2018-06-18 03:59