Web sitesi için yüksek kullanılabilirlik sunmak için doğru zaman ne zaman?

Web sitesi için yüksek kullanılabilirlik sunmak için doğru zaman ne zaman?

Yüksek Kullanılabilirlik seçenekleriyle ilgili birçok makale vardır. Ancak, tek sunucudan yüksek kullanılabilirlik yapılandırmasına geçmek için doğru zaman NEDİR.

Lütfen durumumu göz önünde bulundurun:
http://www.postjobfree.com önemli miktarda trafiğe sahip 7/24 web sitesidir:
http://www.slikeweb.com/website/postjobfree.com

Şu anda tek bir sunucuda çalıştırıyorum: IIS 7.0 web sunucusu ve SQL Server 2008 aynı donanım kutusunda çalışıyor.

Zaman zaman (~ bir ayda bir) ~ 5 dakika kesinti, genellikle bazı Windows Server güncellemelerinin gerektirdiği yeniden başlatmadan kaynaklanır. Genellikle kesinti zamanlanır ve geceleri olur. Yine de rahatsız edici, çünkü Google Bot ve bazı kullanıcılar geceleri hala aktif.

Mevcut web sitesi geliri ayda ~ 8 bin ABD dolarıdır.

İki sunucu yapılandırmasına geçmeyi düşünüyorum (2 web sunucusunun web grubu ve iki donanım sunucusunda barındırılan 2 SQL Sunucusu kümesi).

Artıları:
1) Yüksek Kullanılabilirlik (teorik olarak kesinti yok). Bir sunucu çökse bile, başka bir sunucu devralacaktı.
2) Veri kaybı yok: SQL kümesi olmadan, donanım arızası durumunda bir güne kadar veri kaybedilebilir (günlük yedekleme yaparız).

Eksileri:
1) Bu tür yapılandırmayı ayarlamak ve sürdürmek için daha fazla çaba.
2) Yüksek barındırma maliyeti. Ayda 600 dolar yerine ayda yaklaşık 1200 dolar olur.

Tavsiyen ne olurdu?

Kısa cevap: Kesinti süresi veya riski size yüksek kullanılabilirliğe sahip olmanın maliyetinden daha fazla mal olduğunda.

Temelde ekonomik bir karardır. Örnek olarak. Ayda 8 bin dolar, 2 saatlik bir kesintinin size 22 dolara mal olacağını ima eder. Sisteminizi sıfırdan tamamen işlevsel bir siteye 2 saat içinde gidebilecek şekilde yapılandırabiliyorsanız, yüksek kullanılabilirlik size bunun üstünde sadece 22 $ işlevsellik kazandıracaktır.

Başka bir deyişle, belirli bir ayda 54 saat önlenemez kapalı kalma süreniz olmadıkça / olmadıkça paradan tasarruf edebilirsiniz.

Paydaşlarınız / iş dünyası halkınız (ki siz olabilirsiniz!)

• kabul edilebilir gelir kaybı
• itibar kaybı, saygınlık vb.
• kabul edilebilir veri kaybı ( Kurtarma noktası hedefi )
• kabul edilebilir kesinti süresi ( Kurtarma Süresi Hedefi )

Gelir kaybını ölçmek kolaydır: gerisi burada cevaplanamaz üzgünüm ...

Bence çoğu kullanıcı biraz planlı çalışmama süresini halledebilir. Ebay'ın Cuma geceleri haftalık güncellemeleri olduğunu ve tekliflerin bazen işe yaramadığını düşünün. Benim (büyük avustralya) bankamın çevrimiçi bankacılığı her hafta saatlerce kesinti yapmıştır. Twitter her zaman çevrimdışı olur. Heroku / EC2 son günlerde kapalı kaldı.

Bu perspektifte kalırdım, gerçekten ayda sadece 5 dakika konuşuyorsanız, bir sistem yöneticisi olarak oldukça iyi bir iş çıkarıyorsunuz.

Google'ı zaten endeksleme açısından bir faktör olarak belirtmişsinizdir, ancak gecikme / site yanıt hızının SEO üzerindeki etkisini de göz önünde bulundurmaya değer olabilir. Bu bir kara kutu ve ölçülmesi çok zor - buna rağmen Matt Cutts bunun bir yüzdelik olduğunu düşünüyor . Diğerlerinin de belirttiği gibi, itibar konusunda daha fazla endişe duyarım.

HA'nın güvenlik gibi bir ürün değil, bir süreç olduğunu unutmayın.

Örneğin, veritabanı çoğaltması yalnızca veritabanının her aynasının kendi başına devam edebileceği noktaya gelecektir, ancak başarısız bileşenler değiştirildikten sonra yeniden senkronizasyon için bir stratejiye ihtiyacınız olacaktır.

Bir sipariş sistemini örnek olarak düşünün: müşteri bir sipariş verir ve işleme sırasında, sipariş bilgilerini veritabanının yerel kopyasında sakladıktan sonra konuştuğu fiziksel sistem başarısız olur. Sabırsız, müşteri tekrar "gönder" e basar ve siparişi kabul eden başka bir sunucuya yönlendirilir. Veritabanlarınız diğer tarafta eksik INSERT deyimlerini tekrarlayarak yeniden senkronize ederse, sipariş çoğaltılır, bu da sizin istediğiniz şey olmayabilir.

@Slartibartfast'ın önerdiği gibi, hepsi ekonomik bir karara bağlanır, ancak gelecekte de birkaç yıl planlamanızı tavsiye ederim. Uygun bir HA kurulumuna ihtiyacınız varsa, şimdi hazırlık çalışması için kaynakları ayırmak için iyi bir zaman olacaktır.

Bunu düşünürken bir "başarısız balina" sayfası oluşturmayı düşünüyorum.

Bunu yapmanın birçok yolu var ama route53 ve s3'ün aws kombinasyonu küçük sitelerimde iyi çalışıyor.

Ben hatalar DNS kullanıcıları s3 içinde oturan bir statik html sayfasına gönderir, böylece sağlık kontrolleri ile etki alanı kurmak; Maliyet hiçbir şey yanında.

Deneyimlerime göre sitenize "özür dilerim bozuldu ama üzerinde çalışıyoruz" diyerek kullanıcılar için bir dünya yaratıyor. Kullanıcılarla daha da iletişim kurabileceğiniz bir Twitter hesabı daha da iyidir.

Bu, bir kesintinin en önemli etkisi olabilecek "itibar kaybını" hafifletmek için çok uzundur.

kurulum kılavuzu için bkz. https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ .

DynDns'in sosyal yük devretmesi http://dyn.com/managed-dns/social-failover/ benzer bir şeydir.

DNS kayıtlarınız düşük bir TTL'ye sahipse ve bunları programlı olarak manipüle etmenin bir yolu varsa, kendiniz yuvarlayabilir ve sağlık kontrollerinizi yapabilir ve ardından DNS değişikliklerini komutlayabilirsiniz.

Esnek bir şekilde ölçeklendirmenize ve dezavantajlarınızı reddetmenize izin verecek EC2 gibi bir şey kullanmayı düşündünüz mü? EC2 kullanmanın buna değip değmeyeceği, nihayetinde ekonomik bir karardır, ancak en azından dikkate alınması gereken bir seçenektir.

Veri kaybını önlemek için, kümelerden önce Raid yapılandırmalarına bakmalısınız. Ayrıca, DNS yayılmasını beklemek zorunda kalmadan bir felaket durumunda bir sunucudan diğerine geçebileceğiniz bir Yük Devretme IP'si yapılandırmanız gerekir.