Robocopy ile IIS çoğaltması hakkında WordPress


10

4 IIS sunucusunda bir wordpress ortamı kurduk. Wordpress dizinini her 5 dakikada bir çoğaltmak için bir robokopi komut dosyasını tetikleyen zamanlanmış bir görev kullanmayı düşünüyoruz.

Böyle bir yaklaşım hakkındaki görüşler nelerdir? Bunu ya da benzerlerini kullanan var mı?


4 IIS sunucusu phyical veya VM'si nedir? Verileri veya veritabanlarını ve yapılandırmaları neleri kopyalıyorsunuz? Neden 4 sunucu 1 bir master (varsayalım) ve diğerleri işe yaramaz HA elde etmeye çalışıyorsanız pasif olmak olurdu emin değilim.
Anthony Fornito

1
ikinci soru (ve muhtemelen en önemlisi) neden windows üzerinde wordpress çalıştırıyorsunuz?
Anthony Fornito

Cevabınız için @AnthonyFornito teşekkürler. Dahili nedenlerden dolayı pencerelerde wordpress çalıştırma. Sadece onunla çalışmaya çalışıyorum. Web sitesi dosyalarının çoğaltılmasından sonra (Veritabanı çoğaltma zaten MYSQL ile işlenir). Ön uçlar Azure'daki sanal makinelerdir. Ben esas olarak tüm kullanıcı arabirimlerinin aynı web sitesi dosyalarını paylaştığı bir çözümden sonrayım. Önereceğiniz bir şey var mı?
16:39, joebegborg07

Yanıtlar:


12

Aynı anda aynı dosyaları paylaşan ve her biri dizin senkronizasyonuna adanmış bir tür DFS veya üçüncü taraf programı kullanmadan yazabilen 4 ön uç sunucuya sahip olmak bir gece kısrağı olacaktır.

Azure ile 3 şeye bakabilirsiniz.

  1. Paylaşılan depolama alanı, kendi özel depolama alanınızı almanın bir maliyeti olabilir ve yapılandırmadan emin değilim, ancak Azure bunu sunuyor. Bu, tüm dosyalarınızın yazılır yazılmaz her sunucu tarafından kullanılabilir olmasını sağlar.

  2. Azure DFS, DFS, oldukça iyi çalışan, maliyet konusunda da emin olmayan, ancak yapılandırma biraz daha kolay olabilir, Windows tabanlı bir dizin senkronizasyon aracıdır. DFS eşzamansız olarak çalışır, bu nedenle küçük bir gecikme vardır, ancak çok fazla değildir.

  3. (Bunun nasıl yapılacağını açıklayacağım ve daha sonra asla bir daha konuşmayacağım, çünkü korkunç bir fikir ve başarısız olacak.) Önce dört sunucudaki verileri karşılaştıracak bir komut dosyası oluşturun ve ardından diferansiyel verileri kopyalayın. Her dizini komut dosyasını çalıştıran bir sunucu ile paylaşmanız, sunucunun okuma ve yazma ve ardından sorun giderme, sorun giderme sorunlarını çözebilmesi için kurulum iznini kullanmanız gerekir.

Yukarıdaki seçeneklerden herhangi biri işi yapacaktır, eğer işiniz bu çalışmaya bağlıysa, 3. seçenekten uzak durmanızı tavsiye ederim.

Bununla birlikte, herhangi bir para harcamaya çalışmıyorsanız, aşağıdaki adımları izleyin.

  1. "ücretsiz dosya senkronizasyonu" adlı bir programa bakın. Ücretsiz sürümü için bazı gerçekten iyi özellikler var Ben sürüm için ücretli olduğunu düşünüyorum ama im iyileştirmeler olsun emin değilim. Yapmak istediklerinize benzer bir şey elde etmeye çalışırken birçok geliştirme ortamımda kullandım ve DFS'yi kurmak için tembelleştim.

  2. Yalnızca bir sunucuyu yazılabilir yapın, bu, makale oluşturmanın ServerA'ya gitmesi veya web.config dosyasında bir URL yeniden yazılması veya WordPress'in php kullanımı olduğunu söyleyen her sunucuda bir URI yapılandırılarak kolayca yapılabilir:

    başlık ('Konum: http://myhost.com/mypage.php ');

Her biri biraz kodlama ve PHP, IIS bilgisi alacak.

  1. Gerçekten eğlenceli olan kısım, ServerA'nın yazar sunucu (yalnızca yazılabilir sunucu) olması ile trafiği bir yük dengeleyici olmadan okumak için ServerB, ServerC ve ServerD'ye nasıl yönlendiririz?

Kısa cevap veremezsiniz, bu tam olarak doğru değil, bir kez bir yük balenceresini kullanmama konusunda kararlı olan bir müşterim vardı. işçi her kutu veya benzeri bir şey üzerinde işler. Her iki şekilde de yapmak çok zor ve ortaya koymak için zaman ve enerjiye değmez.

Sunucularda Ağ Yükü Dengeleme işlevini yapılandıramayacağınıza bakın, ek bir IP gerekir, ancak yalnızca bir DNS değişikliği olur ve trafik 3 sunucuda okumak için dağıtılabilir.

İyi şanslar!


Önerileriniz için çok teşekkürler. Biz önce bu kurulum vardı ama yüksek trafik ile başa değildi gibi tek merkezi depolama bizim için bir darboğaz oldu. Son teslim tarihi nedeniyle hızlı bir çözüme ihtiyacımız vardı. Nihayetinde, sunuculardaki değişiklikleri tespit eden ve diğer sunucuya çoğaltılan eşler arası gerçek zamanlı senkronizasyon çözümü olan resilio'yu kullandık. Umarım aynı veya benzer sorunlara sahip olan herkes bu sorunları bizim için olduğu gibi çözebilir. WP arka ucu için URL yeniden yazma önerinizi test ediyor ve değişiklikleri diğer makinelere gönderiyorum. Tekrar teşekkürler.
joebegborg07

NLB Azure'da çalışmaz (gerçekten korkunç kabuslar istiyorsanız, sadece bir Azure VM'deki ARP tablosuna bakmayı deneyin).
Massimo

12

Tüm öneriler için teşekkürler insanlar.

Çözümümüz, resilio adlı bir araç kullanarak eşler arası senkronizasyon yaklaşımı kullanmaktı.

Resilio, eşler arası eşitleme kümesinde birkaç bilgisayarı (bu durumda IIS Front biter) yapılandırmamıza izin verdi. Eşitleme işlemi için kullanılacak kümedeki her bilgisayardan bir klasör seçilir.

Resilio hizmeti (arka planda çalışan windows hizmeti), bu klasörleri herhangi bir değişiklik için izler ve söz konusu kullanıcı arabiriminde belirtilen klasörlerden herhangi birinde bir değişiklik yapılırsa, resilio bu değişikliği diğer sunuculara gönderir.

Umarım bu, gelecekte benzer bir sorunla karşılaşan diğerlerine yardımcı olabilir.


11

Zamanlanmış görevler sanmıyorum ve Robocopy harika bir yaklaşım. 5 dakikalık pencere nedeniyle bir kaynağın istendiği zamanlar olacaktır, ancak yük dengeleyici tarafından seçilen sunucuda kaynak bulunmayacaktır. Büyük ölçüde statik siteler için bu, sık sık değiştirilen yoğun sitelerden çok daha az sıklıkta gerçekleşecektir. Daha yüksek bir frekans veya Bittorrent Sync (şimdi Resilio Sync olarak adlandırılır ) gibi farklı bir senkronizasyon teknolojisi kullanmak bunu biraz iyileştirir, ancak sorunu ortadan kaldırmaz.

Wp içeriğinizi veya belki sadece wp-content / uploads klasörünü paylaşılan bir sürücüye koymak daha iyi bir çözüm olacaktır. Buna bakmanın bir başka yolu, sunuculardan birinin bu klasörü barındırmasını ve diğerlerinin paylaşmasını sağlamaktır. Disk önbellekleme ile sunucu üzerindeki yük diğer sunuculardan çok daha yüksek olmamalıdır.

Güncelleme

Sayfa önbelleğe alma hakkında bu makaleye ve bu CDN için bu makaleye göz atın . Nginx ile ilgilidir, bu yüzden IIS için çalışmanız gerekir, ancak arkasındaki teori herhangi bir web sunucusu için geçerlidir.


Öneriniz için teşekkürler @Tim. Dediğiniz gibi web sitesi dinamiktir, wordpress eklentileri nedeniyle düzenli küçük dosya güncellemeleri vardır; Bu, her kullanıcı arabiriminin zaman zaman farklı dosyalara sahip olabileceği anlamına gelir. Hiç böyle bir üretim ortamını test ettiniz mi (yaklaşık 500 - 1000 eşzamanlı kullanıcı); web sitesi dosyalarını merkezi bir depoda saklamak ve paylaşılan bir sürücü aracılığıyla eşlemek? Evet ise nasıl bir deneyim oldu.
16:37

Hayır, bu senaryoyu test etmedim - CDN'yi önbelleğe aldığım ve kullandığım için buna gerek yok. Arka uç dosya sunucusu dahil olmak üzere ön uç sunucuları sınamanız gerekir. Bununla birlikte, sayfalarınız her kullanıcı sayfası önbelleği için özelleştirilmezse, içerik dağıtımında olduğu gibi yükünüzü büyük ölçüde azaltabilir - CloudFlare'nin ücretsiz bir katmanı vardır. Bu, her 5 dakikada bir güncelleme yapsanız bile geçerlidir. Google "Nginx Microcaching" arkasındaki teori için, ancak açıkça IIS üzerinde farklı uygulamak zorunda kalacaksınız. Bu rotaya giderseniz önbellek başlıkları oldukça kritiktir. Yukarıdaki güncellemeye de bakın.
Tim
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.