Wordpress pada replikasi IIS dengan robocopy


10

Kami menyiapkan lingkungan wordpress di 4 server IIS. Kami sedang mempertimbangkan untuk menggunakan tugas yang dijadwalkan memicu skrip robocopy untuk mereplikasi direktori wordpress setiap 5 menit.

Apa pendapat tentang pendekatan seperti itu? Adakah yang pernah menggunakan ini atau serupa?


Apa 4 server IIS phyical atau VM? Apa yang Anda replikasi data atau database dan konfigurasi? Tidak yakin mengapa Anda memiliki 4 server 1 sebagai master (saya berasumsi) dan yang lain menjadi pasif jika Anda mencoba untuk mencapai HA yang tidak akan berfungsi.
Anthony Fornito

1
pertanyaan kedua (dan mungkin yang paling penting) mengapa Anda menjalankan wordpress di windows?
Anthony Fornito

Terima kasih @AnthonyFornito untuk balasan Anda. Menjalankan wordpress di windows untuk alasan internal. Saya hanya mencoba untuk bekerja dengannya. Saya setelah replikasi file situs web (replikasi Database sudah ditangani melalui MYSQL). Ujung depan adalah VM pada Azure. Saya terutama mencari solusi di mana semua ujung depan berbagi file situs web yang sama. Adakah yang akan Anda sarankan?
joebegborg07

Jawaban:


12

Memiliki 4 server ujung depan yang berbagi file yang sama pada waktu yang sama dan masing-masing dapat menulis tanpa menggunakan semacam DFS atau program pihak ketiga yang didedikasikan untuk sinkronisasi direktori akan menjadi night mare.

Dengan biru Anda dapat melihat 3 hal.

  1. Penyimpanan bersama, mungkin ada beberapa biaya yang terkait dengan mendapatkan penyimpanan khusus Anda sendiri, dan saya tidak yakin dengan konfigurasi namun Azure menawarkan ini. Ini akan memastikan semua file Anda tersedia untuk setiap server segera setelah ditulis.

  2. Azure DFS, DFS adalah alat sinkronisasi direktori berbasis windows yang bekerja dengan baik, juga tidak yakin tentang biaya tetapi konfigurasi mungkin sedikit lebih mudah. DFS memang bekerja secara tidak sinkron sehingga ada sedikit keterlambatan tetapi tidak banyak.

  3. (Saya akan menjelaskan bagaimana ini akan dilakukan dan kemudian tidak pernah membicarakannya lagi, karena itu adalah ide yang mengerikan dan akan gagal.) Buat skrip yang pertama-tama akan membandingkan data pada keempat server kemudian menyalin data diferensial. Anda perlu membagikan masing-masing direktori ke satu server yang menjalankan skrip, mengatur izin sehingga server dapat membaca dan menulis dan kemudian memecahkan masalah memecahkan masalah, memecahkan masalah.

Salah satu opsi dari atas akan melakukan pekerjaan, jika pekerjaan Anda bergantung pada pekerjaan ini, saya sarankan Anda menjauh dari opsi 3.

Yang sedang berkata, dan Anda tidak mencoba menghabiskan uang, ikuti langkah-langkah di bawah ini.

  1. lihat program yang disebut "sinkronisasi file gratis". Ada beberapa fitur yang sangat bagus untuk versi gratis. Saya percaya ada versi berbayar tetapi saya tidak yakin dengan peningkatan yang Anda dapatkan. Saya telah menggunakannya di banyak lingkungan dev saya ketika mencoba untuk mencapai sesuatu yang mirip dengan apa yang Anda ingin lakukan dan malas untuk mengatur DFS.

  2. Buat hanya satu server yang dapat ditulisi, ini dapat dengan mudah dilakukan dengan mengkonfigurasi URI pada setiap server yang mengatakan jika membuat artikel buka ServerA, atau URL menulis ulang di web.config Anda, atau karena WordPress menggunakan php:

    header ('Location: http://myhost.com/mypage.php ');

Masing-masing akan mengambil sedikit pengkodean dan PHP, pengetahuan IIS.

  1. Bagian yang sangat menyenangkan, dengan ServerA menjadi server penulis (hanya server yang dapat ditulis) bagaimana kita mengarahkan lalu lintas ke ServerB, ServerC, dan ServerD untuk membaca tanpa penyeimbang beban?

Jawaban singkat Anda tidak bisa, yah itu tidak sepenuhnya benar, saya pernah memiliki pelanggan yang bersikeras tidak menggunakan load balencer ia mampu melalui serangkaian skrip PowerShell untuk memindahkan koneksi dari satu server ke server lain berdasarkan jumlah proses pekerja pada setiap kotak atau sesuatu seperti itu. Either way sangat sulit dilakukan dan tidak sepadan dengan waktu dan energi untuk diajukan.

Lihat apakah Anda tidak dapat mengonfigurasi Network Load Balancing di server, Ini akan memerlukan IP tambahan tetapi hanya satu perubahan DNS dan lalu lintas dapat didistribusikan untuk dibaca di 3 server.

Semoga berhasil!


Terima kasih banyak atas saran Anda. Penyimpanan pusat tunggal adalah hambatan bagi kami karena kami memiliki pengaturan itu sebelumnya tetapi tidak mengatasi lalu lintas tinggi. Kami membutuhkan solusi cepat karena tenggat waktu. Kami akhirnya menggunakan resilio yang merupakan solusi sinkronisasi real-time peer-to-peer, yang mendeteksi perubahan pada salah satu server dan mereplikasi ke server lain. Saya harap siapa pun yang memiliki masalah yang sama atau serupa dapat menyelesaikan masalah dengan cara yang sama bagi kita. Saya akan menguji saran Anda tentang penulisan ulang URL untuk WP backend dan mendorong perubahan ke mesin lain. Terima kasih lagi.
joebegborg07

NLB tidak bekerja pada Azure (tidak ada layer 2, jika Anda ingin mimpi buruk yang benar-benar mengerikan, cobalah untuk melihat tabel ARP pada Azure VM).
Massimo

12

Terima kasih untuk semua saran orang.

Solusi kami menggunakan pendekatan sinkronisasi peer-to-peer menggunakan alat yang disebut resilio.

Resilio memungkinkan kami untuk mengonfigurasikan sejumlah komputer (dalam hal ini IIS Front berakhir) dalam cluster sinkronisasi peer-to-peer. Folder dipilih dari setiap komputer di cluster yang akan digunakan untuk proses sinkronisasi.

Layanan resilio (layanan windows berjalan di latar belakang), memonitor folder-folder ini untuk setiap perubahan dan jika perubahan dilakukan pada folder yang ditentukan di bagian depan akan dipertanyakan, resilio akan mendorong perubahan itu ke server lain.

Saya harap ini dapat membantu orang lain menghadapi masalah serupa di masa depan.


11

Saya tidak berpikir tugas yang dijadwalkan dan Robocopy adalah pendekatan yang bagus. Karena jendela 5 menit akan ada waktu di mana sumber daya diminta tetapi server yang dipilih oleh load balancer tidak akan memilikinya tersedia. Untuk sebagian besar situs statis ini akan terjadi jauh lebih jarang daripada dengan situs sibuk sering berubah. Frekuensi yang lebih tinggi atau menggunakan teknologi sinkronisasi yang berbeda seperti Bittorrent Sync (sekarang disebut Resilio Sync ) akan meningkatkan ini sedikit, tetapi tidak menghilangkan masalah.

Menempatkan konten wp Anda atau mungkin hanya folder wp-content / upload ke drive bersama akan menjadi solusi yang lebih baik. Cara lain untuk melihatnya adalah dengan meminta salah satu server meng-host folder itu, dan meminta yang lain membaginya. Dengan caching disk, beban pada server seharusnya tidak lebih tinggi dari server lain.

Memperbarui

Lihat artikel ini untuk mengetahui ide tentang caching halaman, dan ini untuk CDN. Ini tentang Nginx sehingga Anda harus mengatasinya untuk IIS, tetapi teori di baliknya valid untuk server web mana pun.


Terima kasih atas saran Anda @Tim. Seperti yang Anda katakan situs web itu dinamis, dengan pembaruan file kecil secara teratur karena ada plugin wordpress; Itu berarti setiap ujung depan mungkin memiliki file yang berbeda di waktu. Apakah Anda pernah menguji lingkungan produksi seperti itu (sekitar 500 - 1000 pengguna bersamaan); yaitu menyimpan file situs web dalam repositori pusat dan dipetakan melalui drive bersama? Jika ya bagaimana pengalamannya.
joebegborg07

Tidak, saya belum menguji skenario itu - saya tidak perlu karena saya cache dan menggunakan CDN. Anda perlu memuat uji server ujung depan termasuk server file ujung belakang. Namun, jika halaman Anda tidak disesuaikan untuk setiap cache halaman pengguna dapat secara besar-besaran mengurangi beban Anda, seperti halnya menggunakan distribusi konten - CloudFlare memiliki tingkat gratis. Ini benar bahkan jika Anda memperbarui setiap 5 menit. Google "Nginx Microcaching" untuk teori di baliknya, tetapi Anda harus menerapkannya secara berbeda pada IIS. Caching header sangat penting jika Anda memilih rute ini. Lihat pembaruan di atas juga.
Tim
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.