Global yüksek kullanılabilirlik kurulum sorusu

Visualwebsiteoptimizer.com / adresine sahibim ve işletiyorum . Uygulama, müşterilerimin belirli metrikleri izlemek için web sitelerine eklediği bir kod snippet'i sağlar. Kod snippet'i harici JavaScript (site kodunun üstünde) olduğundan, bir müşteri web sitesini göstermeden önce, bir ziyaretçinin tarayıcısı uygulama sunucumuzla iletişim kurar. Uygulama sunucumuzun devre dışı kalması durumunda, tarayıcı bağlantı zaman aşımına uğramadan (genellikle 60 saniye) önce bağlantı kurmaya çalışır. Tahmin edebileceğiniz gibi, uygulama sunucumuzu herhangi bir senaryoda kapatmayı göze alamayız çünkü sadece web sitemizi ziyaret edenlerin değil, aynı zamanda müşterilerimizin web sitesi ziyaretçilerinin de deneyimini olumsuz etkileyecektir!

Şu anda farklı bir veri merkezinde (aslında farklı kıtada) bulunan bir yedekleme sunucusuyla DNS yük devretme mekanizmasını kullanıyoruz. Yani, uygulama sunucumuzu 3 ayrı konumdan izliyoruz ve arıza tespit edildiğinde, A kaydını değiştirerek sunucu IP'sini yedekliyoruz. Bu, çoğu tarayıcı için (TTL 2 dakika olduğu için) iyi çalışır, ancak IE, DNS'yi bir anlaşma katili olabilecek 30 dakika boyunca önbelleğe alır. Bu son yayınımıza bakın visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Peki, uygulama veri merkezinin büyük bir kesintiye uğraması durumunda neredeyse anında bir yük devretme sağlamak için ne tür bir kurulum kullanabiliriz? Burada www.tenereillo.com/GSLBPageOfShame.htm adresini okudum , birden fazla A kaydına sahip olmanın bir çözüm olduğunu, ancak oturum senkronizasyonunu karşılayamayacağımızı (henüz). Keşfettiğimiz bir diğer strateji, biri uygulama sunucusuna, ikincisi ise ters bir proxy'ye (farklı bir veri merkezinde bulunur) işaret eden iki A kaydına sahip olmaktır. Bu stratejinin makul olduğunu düşünüyor musunuz?

Sadece önceliklerimizden emin olmak için, kendi web sitemizi veya uygulamamızı aşağıda tutabiliriz, ancak müşterilerimizin hizmet dışı kalma süreleri nedeniyle yavaşlamasına izin veremeyiz. Dolayısıyla, uygulama sunucularımızın devre dışı kalması durumunda varsayılan uygulama yanıtına yanıt vermek istemiyoruz. Boş bir yanıt bile yeterli olacaktır, sadece tarayıcının bu HTTP bağlantısını (ve başka bir şey) tamamlamaması gerekir.

Referans: yararlı olan bu konuyu okudum serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

Durumunuz bizimkine oldukça benziyor. Bölünmüş veri merkezleri ve ağ katmanı tipi yük devretme istiyoruz.

Bunu yapmak için bütçeniz varsa, o zaman istediğiniz, iki veri merkezi, her birine birden fazla IP geçişi, transit sağlayıcılarınıza BGP oturumları yapan ve IP adreslerinizi global internete tanıtan bir çift uç yönlendiricidir.

Gerçek yük devretme yapmanın tek yolu budur. Yönlendiriciler, sunucularınıza giden yolun artık geçerli olmadığını fark ettiğinde (çeşitli yollarla yapabilirsiniz), o zaman bu rotanın reklamını durdurur ve trafik diğer siteye gider.

Sorun şu ki, bir çift uç yönlendirici için, bu kurulumu yapmak için başlangıçta oldukça yüksek bir maliyete bakıyorsunuz.
Ardından, tüm bunların arkasında ağ kurmanız gerekir ve siteleriniz arasındaki bir çeşit Layer2 bağlantısını noktadan noktaya bir bağlantı olarak değerlendirmek isteyebilirsiniz, böylece gelen trafiği tek bir veri merkezine yönlendirebilirsiniz. birincil sitenizin kısmi olarak başarısız olması durumunda doğrudan diğerine.

BGP Multihomed / Multi-location en iyi uygulama ve esnekliği artırmanın en iyi yolu? benzer konular hakkında sorduğum sorular.

GSLB utanç sayfası bazı önemli noktaları ortaya çıkarır, bu yüzden kişisel olarak BGP yönlendirme işini yapmak için asla bir GSLB'yi seçmezdim.

Ayrıca ağınızdaki diğer arıza noktalarına da bakmalısınız. Tüm sunucularda 2 NIC (2 ayrı anahtara bağlı), 2 PSU olduğundan ve hizmetinizin yedek çiftler veya yük dengeli kümeler olarak birden fazla arka uç sunucusundan oluştuğundan emin olun.

Temel olarak, birden fazla A kaydı aracılığıyla DNS "yük dengeleme" yalnızca "yük paylaşımı" dır, çünkü DNS sunucusunun her sunucuda ne kadar yük olduğuna dair bir fikri yoktur. Bu ucuz (ücretsiz).

Bir GSLB hizmeti, sunucuların ne kadar yüklü olduğuna ve kullanılabilirliklerine ilişkin bazı kavramlara sahiptir ve hataya karşı daha büyük bir direnç sağlar, ancak dns önbelleğe alma ve pimleme ile ilgili sorunlardan hala rahatsız olur. Bu daha ucuz, ama biraz daha iyi.

Sağlam bir altyapı ile desteklenen bir BGP yönlendirmeli ağ, iyi çalışma süresini gerçekten garanti etmenin tek yolu IMHO'dur. Cisco / Juniper / etc yönlendiricileri yerine rota sunucuları kullanarak biraz tasarruf edebilirsiniz, ancak günün sonunda bu sunucuları çok dikkatli bir şekilde yönetmeniz gerekir. Bu hiçbir şekilde ucuz bir seçenek ya da hafifçe üstlenilecek bir şey değildir, ancak çok ödüllendirici bir çözümdür ve sizi sadece bir tüketici değil, bir sağlayıcı olarak internete getirir.

Tamam, bu bir süre önce istendi, ama şimdi görüyorum.

kod snippet'i harici bir JavaScripttir (site kodunun üstünde), bir müşteri web sitesini göstermeden önce, bir ziyaretçinin tarayıcısı uygulama sunucumuzla iletişim kurar.

Malısın:

1. Javascript dosyanızı iyi, profesyonel bir İçerik Dağıtım Ağına yerleştirin, yani bu uzmanlığa sahip birinden Javascript'in yüksek oranda kullanılabilir HTTP (S) sunumunu satın alın.
2. Javascript'inizi iyi bir geri dönüş durumu olacak şekilde programlayın, yani uygulama sunucunuz hızlı bir şekilde yanıt vermezse, son kullanıcı normal ve değiştirilmemiş bir sayfa görür.

Başka bir şey yapmak gerçekten sorumsuz. Bunun yerinde olduğunu varsayıyorum.

Bu konuda bilgi sahibi olmadığınız veya bu konuda bilgi sahibi olmadığınız sürece hizmetinizi BGP yönlendirme hilelerine dayandırmamalısınız. Karmaşık BGP yönlendirme senaryolarının uygulanması kesinlikle önemsiz değildir; etki alanına özgü bilginiz yoksa bunu kendiniz yapmayın.

Sorunuzun kendisi biraz karışık. Yüksek düzeyde kullanılabilir bir hizmetin nasıl oluşturulacağının analizi uygulama verileriyle başlar , çünkü bu sizin “durumunuz” dur. Vatansız parçaların yüksek oranda kullanılabilir olması kolaydır, tam dolu parçalar değildir. Dolayısıyla, sunucularınıza ve DNS'nize odaklanmak yerine, uygulamanızın durumu nerede koruduğuna bakın . Oraya optimize ederek ve muhtemelen Yığın Taşması hakkında algoritma tavsiyesi isteyerek başlayın. Javascript fx dosyanızda bir işlem kavramı ve akıllı sunucu yeniden denemesi yapabilir misiniz?

Aslında, geodns ve dns yük devretmeyi birleştirirseniz, bölünmüş test etkinliklerinize yardımcı olmak için istediğiniz şey yükseltilebilir.

Aynı sunucuda olsalar bile A grubundan ip 1'e ve B grubundan ip 2'ye göndermek, test gruplarınızı ayırmanıza izin verir. A Grubu ve B Grubu farklı coğrafi bölgelerdendir. Adil olmak gerekirse, ertesi gün / hafta / ay, coğrafi farklılıklara izin verdiğinizden emin olmak için grupları çevirirsiniz. Sadece metodolojinizde titiz olmak.

Http://edgedirector.com adresindeki geodns / failover dns hizmeti bunu yapabilir

açıklama: ben yukarıdaki bağlantı ile ilişkili, burada aptal dns hileler bölünmüş test uygulama hakkında bir makale araştırma tökezledi.