Bir web uygulaması için% 100 çalışma süresi

Bugün bir müşteriden ilginç bir "gereksinim" aldık.

Bir web uygulamasında saha dışı yük devretme ile% 100 çalışma süresi istiyorlar . Web uygulamamızın bakış açısından bu bir sorun değil. Birden fazla veritabanı sunucusu arasında vb. Ölçeklendirme yapabilmek için tasarlanmıştır.

Bununla birlikte, bir ağ oluşturma sorunundan, nasıl çalışacağını çözemiyorum.

Özetle, uygulama müşterinin ağındaki sunucularda yaşar. Hem iç hem de dış insanlar tarafından erişilebilir. Kendi tesislerinde ciddi bir başarısızlık olması durumunda derhal alınacak ve devralınacak olan sistemin saha dışı bir kopyasını korumamızı istiyorlar.

Artık, iç insanlar için (taşıyıcı güvercin mi?) Bunu çözmenin kesinlikle bir yolu olmadığını biliyoruz, ancak dış kullanıcıların farkına bile varmadıklarını istiyorlar.

Açıkçası, bunun nasıl mümkün olabileceği konusunda en ufak bir fikrim yok. İnternet bağlantısını kaybederlerse, trafiği harici makinelere yönlendirmek için bir DNS değişikliği yapmak zorunda kalacağız gibi görünüyor ... Tabii ki, zaman alıyor.

Fikirler?

GÜNCELLEME

Bugün müşteriyle bir tartışma yaptım ve konuya açıklık getirdiler.

Başvuranın bir sel durumunda bile aktif kalması gerektiğini söyleyerek% 100 sayısına sıkıştılar. Bununla birlikte, bu gereksinim sadece onlar için ev sahipliği yaparsak devreye girer. Uygulama tamamen kendi sunucularında yaşıyorsa, çalışma süresi şartını yerine getireceklerini söylediler. Cevabımı tahmin edebilirsiniz.

İşte Vikipedi'nin dokuz arayışı hakkındaki pratik çizelgesi:

İlginçtir ki, ilk 20 web sitesinden sadece 3'ü 2007'de efsanevi 5 dokuz ya da% 99,999 çalışma süresine ulaşabildi. Yahoo, AOL ve Comcast. 2008 yılının ilk 4 ayında, en popüler sosyal ağların bazıları buna yaklaşamadı bile.

Grafikten,% 100 çalışma zamanının peşinde koşmanın ne kadar saçma olduğu ...

Onlardan% 100 ve nasıl ölçüleceğini hangi zaman aralığında ölçmelerini isteyin. Muhtemelen karşılayabilecekleri% 100'e yakın demek istiyorlar. Masrafları onlara ver.

Detaylandırmak için. Müşterilerle yıllar içinde sözde gülünç şartlar ile görüşmeler yaptım. Her durumda, aslında sadece yeterince kesin olmayan bir dil kullanıyorlardı.

Oldukça sıkça, işleri% 100 gibi mutlak görünen şekillerde çerçevelerler ancak% 100 daha derinlemesine incelemelerde, aslında azaltma verilerinin risklenmesi için maliyetlerle sunulduğunda gereken maliyet / fayda analizlerini yapacak kadar makul olurlar. Kullanılabilirliği nasıl ölçeceklerini sormak çok önemli bir sorudur. Bunu bilmiyorlarsa, o zaman onlara önce bunun tanımlanması gerektiğini önermek zorunda kalacaksınız.

Müşteriden, site aşağıdaki durumlarda kullanılamazsa ticari etki / maliyetler açısından ne olacağını tanımlamasını isterim:

• En yoğun saatlerinde x saat
• En az meşgul saatlerinde x saat

Ve ayrıca bunu nasıl ölçeceklerini.

Bu şekilde '% 100' doğru seviyesini belirlemek için onlarla birlikte çalışabilirsiniz. Bu tür soruları sorarak, diğer gereksinimlerinin önceliklerini daha iyi belirleyebileceklerinden şüpheleniyorum. Örneğin, belirli seviyelerde SLA ödemek ve bunu başarmak için diğer işlevlerden ödün vermek isteyebilirler.

Müşterilerin deli. Ne kadar para harcadığınız önemli değil ,% 100 çalışma süresi mümkün değildir . Sade ve basit - imkansız. Google’a, Amazon’a vb. Bakın. Altyapılarına atmak için neredeyse sonsuz miktarda paraya sahipler, ancak yine de kesinti süreleri var. Bu mesajı onlara iletmeniz gerekir ve makul taleplerde bulunmaları konusunda ısrar etmeye devam ederlerse. Onlar tanımıyorsanız bazı kesinti miktarı kaçınılmazdır, o zaman onları hendek.

Bununla birlikte, uygulamanın kendisini ölçeklendirme / dağıtma mekaniğine sahip görünüyorsunuz. Ağ oluşturma bölümünün, farklı ISS'lere yedekli yukarı bağlantılar, ASN ve IP tahsisi alması ve BGP'de ve gerçek yönlendirme donanımında boyun derinliği alması, gerekirse IP adres alanının ISS'ler arasında hareket edebilmesi gerekir.

Bu, açık bir şekilde, çok özlü bir cevaptır. Bu derece çalışma süresi gerektiren uygulamalarla ilgili deneyiminiz olmadı, bu yüzden efsanevi% 100 çalışma zamanına yakın bir yere ulaşmak istiyorsanız, gerçekten profesyonel bir uzmana ihtiyacınız var.

Bu kesinlikle ilginç bir şey. Kendimi sözleşmeli olarak% 100 çalışma süresiyle mecbur etmek istediğimden emin değilim, fakat eğer zorunda olsaydım, bunun gibi bir şey olacağını düşünürdüm:

Tamamen ağ üzerindeki bir yük dengeleyicisinde halka açık IP ile başlayın ve bunlardan en az ikisini oluşturun, böylece biri diğerine geçemez. Heatbeart gibi bir program, bunların otomatik yerine çalışma ile yardımcı olabilir.

Cila, öncelikle önbellekleme çözümü olarak bilinir, ancak bazı çok iyi yük dengelemeleri de yapar. Belki de bu, yük dengelemesinin üstesinden gelmek için iyi bir seçim olabilir. İsteğe bağlı olarak rasgele veya yuvarlak robin dengesi yükleyecek olan yöneticilerde gruplandırılmış 1 ila n arka ucu olacak şekilde ayarlanabilir. Vernik, her arka ucun sağlığını kontrol etmeye ve sağlıksız arka uçları çevrimiçine geri dönene kadar döngüden çıkarmak için yeterince akıllı hale getirilebilir. Arka uçların aynı ağda olması gerekmez.

Amazon EC2'deki Elastik IP'lere bugünlerde aşık oldum, bu yüzden muhtemelen yük dengeleyicilerimi EC2'de farklı bölgelerde veya en azından aynı bölgede bulunan farklı bölgelerde bulabilirim. Bu, mevcut A kayıt IP'sini yeni kutuya taşımak ve taşımak zorunda olmanız durumunda, yeni bir yük dengeleyicisini el ile açma (tanrı korusun) seçeneğini sunar.

Cila, SSL'yi sonlandıramaz, ancak bu bir endişe ise Nginx gibi bir şeye bakmak isteyebilirsiniz.

Arka uçlarınızın çoğunu müşteri ağınızda ve ağlarının dışında bir veya daha fazla olabilir. İnanıyorum, ancak% 100 emin değilim, arka uçları önceliklendirebilir, böylece müşterilerinizin makineleri sağlıksız hale gelene kadar öncelik kazanırlar.

İşte bu görevde olsaydım başaracağım ve hiç şüphesiz devam ettikçe düzeltmeliyim.

Ancak, @ErikA'nın belirttiği gibi, İnternet ve ağın her zaman kontrolünüz dışında olan kısımları olacak. Yasal olanınızın yalnızca kontrolünüz altındaki şeylerle sizi bağladığından emin olmak isteyeceksiniz.

Hiç sorun değil - biraz gözden geçirilmiş sözleşme ifadesi olsa:

...% 100 çalışma süresi garantisi (sıfır ondalık basamağa yuvarlanmış).

Facebook ve Amazon yapamazsa, yapamazsınız. Bu kadar basit.

Hacker'ın cevabını Hacker News'den eklemek

Sorunun ne olduğunu anlamıyorum. Müşteri felaketi planlamanı istiyor ve matematik odaklı değil,% 100 olasılık sormak mantıklı geliyor. Mühendisler yapmaya eğilimli olan mühendis, müşterinin yapamayacağını düşünmeden, prob & stat 101'in ilk gününü hatırladı. Bunu söylediklerinde nükleer kış hakkında düşünmüyorlar, Fred'in kahvesini ofis sunucusuna atmasını, bir disk çökmesini veya bir ISS'nin düşmesini düşünüyorlar. Ayrıca, bunu başarabilirsiniz. Coğrafi olarak farklı, bağımsız, kendi kendini izleyen sunucularla, hiçbir zaman kesinti yaşamayacaksınız. Bağımsız çalışan (1) üç 9 güvenilirlikte çalışan 3 sunucu ile iyi yük devretme modları, beklenen arıza süreniz yılda bir saniyenin altındadır (2). Bunların hepsi bir kerede olsa bile, web bağlantıları için hala makul bir SLA içerisindesiniz ve bu nedenle kesinti pratik olarak mevcut değil. Müşteri hala kıyamet senaryolarıyla ilgilenmek zorundadır, ancak Godzilla, "her zaman" açık bir hizmete sahip olamayacağını söyledi.

(1) LA’daki bir sunucu Boston’daki sunucudan oldukça bağımsızdır, ancak evet, anlıyorum ki nükleer savaş, Çinli hackerların elektrik şebekesini çökertmesi gibi bazı kesişmeler var. Müşterinizin üzüleceğini sanmıyorum. bu.

(2) DNS yerine çalışma birkaç saniye ekleyebilir. Hala müşterinin yılda bir kez, bir kez daha makul bir SLA içinde olan ve genellikle "kesinti süresi" ile aynı şekilde kabul edilmeyen bir talebi tekrar denemesi gerektiği bir senaryodasınız. Arıza durumunda otomatik olarak uygun bir düğüme yönlendiren bir uygulama ile, bu farkedilemez olabilir.

Sizden imkansız bir şey isteniyor.

Buradaki diğer cevapları inceleyin, müşterinizle oturun ve NEDEN imkansız olduğunu açıklayın ve cevaplarını ölçün.

Halen% 100 çalışma süresinde hala ısrar ediyorlarsa, yapamadıklarını kibarca onlara bildir ve sözleşmeyi reddet. Taleplerini hiçbir zaman karşılamayacaksın ve sözleşme tamamen emilmezse cezalarla çarpışacaksın.

Buna göre fiyat, ve sonra sözleşmede SLA geçen herhangi bir kesinti ödedikleri oranda iade edileceğini öngörmektedir.

ISS benim son işimde bunu yaptı. "Düzenli" bir DSL hattı için 40 $ / ay için% 99,9 çalışma süresi veya 1100 $ / ay için% 99,99 çalışma süresi için bağlı bir T1 üçlüsü tercih ettik. Aylık 10+ saatin sık sık kesintileri oldu, bu da çalışma sürelerini 40 $ / mo DSL'nin çok altına çıkardı, ancak biz sadece 15 $ civarında bir ücret iadesi aldık, çünkü saat başına ücretin * saatinin üstünde olduğu şeydi. Anlaşmadaki haydutlar gibi seviştiler.

% 100 çalışma süresi için ayda 450.000 ABD doları fatura keserseniz ve yalnızca% 99,999'u atarsanız, onlara 324 ABD doları geri ödemeniz gerekir. % 99,999'a varacak altyapı maliyetlerinin, aylık olarak 45,000 dolar civarında mahallede bulunduğunu iddia ediyorum.

Eğer uzmanlar yüzde 99,999 mevcudiyetinin pratik veya finansal olarak uygulanabilir bir olasılık olup olmadığını sorguluyorsa , o zaman% 99,9999 mevcudiyet daha az mümkün veya pratiktir. % 100 yalnız bırak.

Uzun süre% 100 kullanılabilirlik hedefine ulaşamayacaksın. Bir hafta veya bir yıl boyunca ondan kurtulabilirsin, ama sonra bir şeyler olacak ve sen sorumlu olacaksın. Düşüş, hasar görmüş itibardan (söz verdiğiniz, sağlamadığınız) sözleşmeden doğan cezalardan iflasa kadar değişebilir.

% 100 çalışma süresi isteyen iki tür insan vardır:

1. Bilgisayarlar, bilgisayar sistemleri veya İnternet hakkında kesinlikle bilgisi olmayan kişiler. *
2. Kasıtlı olarak kıçını kıranlar, ya Hayır (Google "Portakal Suyu Testi") deme yeteneğinizi test etmek ya da size sonradan ödeme yapmak üzere bir tür SLA kaldıraç gücü kazanmaya çalışmak.

Bu tür müşterilerin her ikisinde de sık sık acı çeken tavsiyem, bu müşteriyi almamak. Başka birini delirtmelerine izin verin.

* Aynı kişi, Işıktan Hızlı seyahat, Perpetual Motion, Cold Fusion, vb. Hakkında utanç duymaz.

Müşteri ile onlarla% 100 çalışma süresinin ne anlama geldiğini belirlemek için iletişim kurardım. % 99 çalışma süresi ile% 100 çalışma süresi arasında bir ayrım görmüyor olmaları mümkündür. Çoğu insan için (yani sunucu yöneticileri değil) bu iki sayı aynıdır.

% 100 çalışma süresi?

İşte ihtiyacın olan şey:

Her ISP'de uygun SLA'lar ile dünyanın her yerinde birden fazla siteye işaret eden çoklu (ve yedekli) DNS sunucuları.

DNS sunucularının doğru şekilde ayarlandığından ve TTL'nin etkili bir şekilde tanındığından emin olun.

Bu kolay. Amazon EC2 SLA açıkça şunları söylüyor:

“Yıllık Çalışma Süresi Yüzdesi”, Amazon EC2'nin “Kullanılamayan Bölge” durumunda olduğu Hizmet Yılı içerisinde 5 dakikalık sürelerin yüzdesinin% 100'ünden çıkarılarak hesaplanır.

http://aws.amazon.com/ec2-sla/

Sadece 'çalışma süresini', hizmetin tüm zamanının% 100'ünü çalıştırabileceğiniz tüm hizmet paketine göre tanımlayın ve hiçbir problem yaşamayacaksınız.

Ayrıca, bir SLA'nın tüm amacının yükümlülüklerinizin ne olduğunu ve bunlarla başa çıkamadığınızda ne olacağını tanımlamak olduğuna değinmeye değer. Müşterinin 3 veya 5 dokuz veya bir milyon dokuzluk bir soru sorması farketmez - soru, ne zaman / ne zaman teslim edemezsiniz. Açıkça cevaplandırılması, 5x ücretlendirmek istediğiniz fiyatta% 100 çalışma süresi için bir satır öğesi sağlamaktır ve ardından bu hedefi kaçırırsanız 4x geri ödeme alırlar. Puan olabilir!

DNS değişiklikleri yalnızca zaman alacak şekilde yapılandırıldıysa zaman alır. TTL'yi bir saniyede bir kayda ayarlayabilirsiniz - tek sorununuz DNS sorgularına zamanında yanıt vermenizi sağlamak ve DNS sunucularının bu düzeydeki sorgularla başa çıkabilmesini sağlamak olacaktır.

GTM F5 Big IP’de tam olarak böyle çalışıyor - varsayılan olarak DNS TTL 30 saniyeye ayarlanmış ve küme üyelerinden birinin devralması gerekiyorsa, DNS güncellendi ve hemen hemen yeni IP alındı. Maksimum 30 saniye kesinti, ancak bu son durumda, ortalama 15 saniye olur.

Bunun imkansız olduğunu biliyorsun.

Hiç şüphe yok ki, müşteri "% 100" görmeye odaklanmıştır, bu yüzden yapabileceğiniz en iyisi, [sizin suçunuz olmayan tüm makul sebepler] hariç% 100 söz vermektir.

% 100 'ün mümkün olabileceğinden şüpheliyim, Azure'u (veya benzer bir SLA'ya sahip bir şeyi) bir olasılık olarak düşünebilirsiniz. Nasıl gidiyor:

Sunucularınız sanal makinelerdir. Bir sunucuda bir donanım sorunu varsa, sanal makineniz yeni bir makineye taşınır. Yük dengeleyici, yeniden yönlendirmeyi önemser, böylece müşteri herhangi bir kesinti görmemelidir (oturumlarınızın durumunun nasıl etkileneceğinden emin değilim).

Bununla birlikte, bu başarısızlıkla bile, 99.999 ile 100 arasındaki farkın delilikle sınırı olduğunu söyledi.

Aşağıdaki faktörler üzerinde tam kontrol sahibi olmanız gerekir.
- Hem iç hem de dış olan insan faktörleri, hem kötüye hem de iktidarsızlığa neden olur. Buna bir örnek, sunucuyu indiren üretim koduna bir şey iten birisidir. Daha da kötüsü, peki ya sabotaj?
- İş meseleleri. Eğer sağlayıcınız elektrik faturalarını ödemeyi başaramazsa veya unutmayı ya da altyapınızı yeterli uyarı olmadan desteklemeyi bırakmaya karar verirse ne olur?
- Doğa. İlişkili olmayan kasırgalar eşzamanlı olarak yedekleme kapasitesini zorlamak için yeterli veri merkezine çarptığında ne olur?
- Tamamen hatasız bir ortam. Bazı üçüncü parti ya da çekirdek sistem kontrolünde kendini göstermeyen ancak gelecekte de bunu yapabilecek bir kenar davası olmadığından emin misiniz ?
- Yukarıdaki faktörler üzerinde tam kontrol sahibi olsanız bile, sisteminizin çalışıp çalışmadığını kontrol ederken yazılımı / kişinin bunu yanlış negatiflerle karşılamayacağından emin misiniz?

Dürüst olmak gerekirse,% 100 en az bir hack saldırısı açısından bir dalgalanma olmadan tamamen delilik. Sitenizin ve DB'nin birden fazla coğrafi konumda birden fazla sunucu arasında çoğaltıldığı coğrafi olarak dağıtılmış bir barındırma çözümünüz olması için Google ve Amazon’un yaptığı şeyi yapmak en iyisidir. Bu, internet omurgasının bir bölgeye kesilmesi (zaman zaman gerçekleşen) veya neredeyse kıyamet gibi bir şey gibi büyük bir felaketten başka bir şey olduğunu garanti edecektir.

Sadece bu gibi durumlar için bir cümle koyardım (DDOS, internet omurga kesimi, kıyamet terörist saldırısı veya büyük bir savaş, vb.).

Bunun dışında Amazon S3 veya Rackspace bulut servislerine bakabilirsiniz. Temel olarak bulut kurulumu, her konumdaki artıklığı değil, aynı zamanda trafiğin ölçeklenebilirliğini ve coğrafi dağılımını ve başarısız coğrafi bölgeleri yeniden yönlendirme özelliğini de sunacak. Anladığım kadarıyla, coğrafi dağılım daha fazla paraya mal oluyor.

Ben sadece " yapılabilir (teorik olarak yapılabilir)" partisine başka bir ses eklemek istedim .

Bana ne kadar ödediklerine bakılmaksızın, belirtilen bir sözleşmeyi kabul etmem, ancak bir araştırma problemi olarak, oldukça ilginç çözümleri var. Aşamaları belirtmek için ağ oluşturma konusunda yeterince bilgi sahibi değilim, ancak ağla ilgili yapılandırmaların + elektrik / donanım kablolama başarısızlıklarının + yazılım başarısızlıklarının bir kombinasyonunu ya da aslında başka bir yapılandırmada fiilen çekip çıkarmayacağını düşünüyorum.

Herhangi bir konfigürasyonda bir yerde neredeyse her zaman tek bir hata noktası vardır, ancak yeterince sıkı çalışırsanız, bu başarısızlık noktasını "canlı" olarak düzeltilebilecek bir şey olmak için zorlayabilirsiniz (örneğin, kök dns düşer, ancak değerler hala önbelleğe alınır) başka her yerde bu yüzden düzeltmek için zamanınız var).

Yine, bunun mümkün olduğunu söylemiyorum .. Ben sadece tek bir cevabın "orada bir çıkış yolu" olmadığı gerçeğine değinmediğini beğenmedim - sadece düşünürlerse aslında istedikleri bir şey değil.

Kullanılabilirliği ölçme metodolojinizi tekrar düşünün ve anlamlı hedefler belirlemek için müşterinizle birlikte çalışın .

Büyük bir web sitesi kullanıyorsanız, çalışma süresi hiç de faydalı değildir. Müşterilerinize en çok ihtiyaç duyduklarında (trafik yoğunluğu) sorguları 10 dakika boyunca bırakırsanız, bir Pazar günü saat 3: 00'te bir saatlik bir kesintiden çok işletmeye zarar verebilir.

Bazen büyük web şirketleri, aşağıdaki ölçümleri kullanarak kullanılabilirliği veya güvenilirliği ölçer:

1. Sunucu tarafı hatası olmadan (HTTP 500'ler) başarıyla yanıtlanan sorguların yüzdesi .
2. Belli bir hedef gecikme altında cevaplanan sorguların yüzdesi .
3. bırakılan sorguların istatistiklerinize göre sayılması gerekir (aşağıya bakın).

Durumu gerektiğini değil böyle Pingdom ve pingability gibi harici bir varlık rapor edebiliyoruz budur, örnek problar kullanılarak ölçülebilir. Sadece buna güvenme. Doğru yapmak istiyorsanız, her sorguda sayılmalıdır . Gerçek, algılanan başarınıza bakarak uygunluğunuzu ölçün.

En etkili yöntem, yük dengeleyicinizden günlükleri veya istatistikleri toplamak ve yukarıdaki ölçümlere göre kullanılabilirliği hesaplamaktır.

Bırakılan sorguların yüzdesi de istatistikleriniz için sayılmalıdır. Sunucu tarafı hatalarıyla aynı kovada hesaplanabilir. Ağda veya DNS veya yük dengeleyici gibi başka bir altyapıda sorun varsa, kaç sorgu kaybettiğinizi tahmin etmek için basit bir matematik kullanabilirsiniz . Haftanın o günü için X sorgusu bekliyorsanız ancak X-1000'iniz varsa, muhtemelen 1000 sorgu bıraktınız. Trafiğinizi dakika başına (veya saniye) grafik başına sorgulara yerleştirin. Boşluklar görünürse, sorguları bıraktınız. Toplam bırakılan sorgu sayısını veren bu boşlukların alanını ölçmek için temel geometri kullanın .

Bu metodolojiyi müşterinizle tartışın ve faydalarını açıklayın. Mevcut kullanılabilirliğini ölçerek bir taban çizgisi ayarlayın . % 100 imkansız bir hedef olduğu onlara açıklık kazanacaktır.

Ardından, mevcut durumdaki iyileştirmelere dayanarak bir sözleşme imzalayabilirsiniz. Örneğin, şu anda kullanılabilirliğin% 95'ini yaşıyorlarsa, durumu % 98,5'e çıkararak durumu on kat artıracağına söz verebilirsin .

Not: Bu ölçüm durumunun dezavantajları vardır. İlk olarak, günlükleri toplamak, raporları kendiniz işlemek ve oluşturmak, yapmak için mevcut araçları kullanmadığınız sürece önemsiz olmayabilir. İkinci olarak, uygulama hataları uygunluk durumunuza zarar verebilir. Uygulama düşük kaliteli ise, daha fazla hataya hizmet edecektir. Bunun çözümü, uygulamadan gelenler yerine yalnızca yük dengeleyici tarafından oluşturulan 500'leri dikkate almaktır.

İşler bu şekilde biraz karmaşık olabilir, ancak bu yalnızca sunucunuzun çalışma süresini ölçmenin bir adım ötesinde .

Bazı insanlar burada belirtmiş olsa da,% 100 delilik veya imkansız , bir şekilde asıl noktayı kaçırdılar. Bunun sebebinin, en iyi şirketler / hizmetler bile bunu başaramadığı gerçeği olduğunu savundu.

Bundan çok daha basit. Bu var matematiksel olarak imkansız .

Her şeyin bir olasılığı var. Sunucularınızı sakladığınız tüm yerlerde, hepsini yok ederek eşzamanlı bir deprem olabilir. Kabul edilebilir bir şekilde gülünç derecede küçük bir olasılık, ancak 0 değil. İnternet sağlayıcılarınız eşzamanlı bir terörist / siber saldırı ile karşı karşıya kalabilir. Yine, çok muhtemel değil, ama sıfır da değil. Ne sağlarsanız yapın, tüm hizmeti azaltan sıfır olmayan bir olasılık senaryosunu elde edebilirsiniz. Çünkü bu, çalışma zamanınız da% 100 olamaz.

İstatistiki örneklemeyi kullanarak imalat kalite kontrolü hakkında bir kitap edinin. Herhangi bir menajerin kolejdeki genel bir istatistik kursunda maruz kalacağı kavramları genel bir tartışma, binin 1 istisnasından binde 1, binde 10 binde 1'e gitmek için gereken maliyetleri belirledi. Üstelik 1 milyarda artış. Temel olarak% 100 çalışma süresine ulaşma yeteneği, bir nesneyi ışık hızına itmek için gereken yakıt miktarı gibi, neredeyse sınırsız miktarda paraya mal olur.

Bir performans mühendisliği bakış açısından, bu ifadeyi hem denenemez hem de mantıksız olarak reddederdim, bu ifadenin gerçek bir gereksinimden çok bir arzudur. Ağ oluşturma, ad çözümleme, yönlendirme, altta yatan mimari bileşenlerden veya geliştirme araçlarından kaynaklanan hatalar için herhangi bir uygulamanın dışında kalan uygulama bağımlılıkları ile, herhangi bir kimseye% 100 çalışma süresi garantisi vermesi pratik bir olanaksızlık haline gelir.

Müşterinin aslında% 100 çalışma süresi, hatta% 99.999 çalışma süresi istediğini sanmıyorum. Eğer tarif ettikleri şeye bakarsanız, bir meteor site veri merkezlerini çıkarırsa bıraktıkları yerden almaktan bahsediyorlar.

Gereklilik dış insanlar tarafından bile fark edilmezse, bunun ne kadar sert olması gerekiyor? Bir Ajax isteğinin tekrar denenmesi ve son kullanıcının 30 saniye boyunca bir iplikçi göstermesi kabul edilebilir mi?

Bunlar müşterinin umursadığı şeylerdir. Müşteri gerçekten doğru SLA'ları düşünüyor olsaydı, bunu 99.99 ya da 99.999 olarak ifade edecek kadar çok şey bilirdi.

2 sentim. Süper kase için reklamlar çıkaran bir servet-5 şirketi için çok popüler bir web sitesinden sorumluydum. Trafikteki büyük ani artışlarla uğraşmak zorunda kaldım ve çözdüğüm yol Akamai gibi bir servisi kullanmaktı. Akamai için çalışmıyorum ama hizmetlerini çok iyi buldum. Belirli bir düğüm / ev sahibi ile ağır yük altında olduğunu veya kapalı olduğunu ve trafiğini buna göre yönlendirebilen, daha akıllı bir DNS sistemine sahipler.

Servisleriyle ilgili en güzel şey, kendi veri merkezimdeki sunuculardaki içeriği kendi veri merkezlerine çoğaltmak için çok karmaşık bir şey yapmak zorunda olmadığımdı. Ek olarak, onlarla çalışmanın da Apache HTTP sunucularını yoğun kullandıklarını biliyorum.

% 100 çalışma süresi olmasa da, içeriği dünyaya dağıtmak için bu seçenekleri düşünebilirsiniz. Anladığım kadarıyla Akamai, Michigan'da olsaydım, Michigan / Chicago sunucusundan içerik alıp Kaliforniya'daysam, Kaliforniya merkezli bir sunucudan içeriğimi aldım.

Site dışı yük devretme yerine, uygulamayı aynı anda iki yerden aynı anda, dahili ve harici olarak çalıştırın. Ve iki veritabanını senkronize et ... Sonra eğer iç inerse, iç insanlar hala çalışabilecek ve dış insanlar da uygulamayı kullanabilecekler. Dahili tekrar çevrimiçi olduğunda, değişiklikleri senkronize edin. Bir etki alanı adı ya da yuvarlak robinli bir ağ yönlendiricisi için iki DNS girişi olabilir.

Harici olarak barındırılan siteler için,% 100 çalışma süresine en yakın olanı sitenizi Google'ın Uygulama Motorunda barındırmak ve verilerinizi gerçek zamanlı olarak en az üç veri merkezinde otomatik olarak çoğaltan yüksek çoğaltma veri deposunu (HRD) kullanmaktır . Aynı şekilde, App Engine ön uç sunucuları da sizin için otomatik olarak ölçeklenir / çoğaltılır.

Bununla birlikte, Google’ın tüm kaynakları ve dünyadaki en gelişmiş platformla bile, App Engine SLA çalışma süresi garantisi, herhangi bir takvim ayı içinde yalnızca zamanın% 99,95'idir.

Basit ve doğrudan: Anycast

http://en.wikipedia.org/wiki/Anycast

Cloudflare, google ve diğer büyük şirketlerin gereksiz, düşük gecikmeli, kıtasal başarısızlık / dengeleme yapmak için kullandıkları şey budur.

Ancak% 100 çalışma süresine sahip olmanın imkansız olduğunu ve% 99,999'dan% 99,9999'a gitmenin maliyetlerinin çok daha büyük olduğunu unutmayın.