Bant genişliği dağıtımı için bile birden çok statik dosya sunucusunda denge kurmanın en iyi yolu?


12

Öncelikle, durumumu size açıklayacağım. Bir yan proje olarak oldukça popüler bir web sitesi çalıştırıyorum, bu yüzden gerçekten bir ton para yatırım yapamıyorum. Şu anda ön HAProxy ile Apache'ye normal istekleri ve Lighttpd'ye tüm statik dosya isteklerini gönderen sadece bir sunucum var. Tüm resimler daha hızlı Lighttpd'e gönderilirken (php ve post istekleri Apache tarafından işlenir çünkü bu gerçekten iyi çalışıyor (site çoğunlukla resimlerdir, bu yüzden bu gerçekten önemlidir). Kısa URL'ler de gerçekten önemli olduğundan, bu nedenle HAProxy kullanma nedenim, görüntüleri sunmak için bir alt alan adı ayarlamak zorunda kalmamak güzel olurdu.

Kullandığım oldukça ucuz ölçülmemiş bant genişliği sunan bir barındırma sağlayıcı buldum, 100mbs ağ kartı işleyebildiği kadar bant genişliğini dışarı itmeye başladığımda sorun geliyor, böylece ikinci bir sunucuya ihtiyaç duyuyorum.

Seçeneklerime çok fazla düşünce koydum, bu yüzden her birini size açıklayacağım. Umarım hangisinin benim için en iyi seçenek olduğu konusunda bir fikir verebilirsin, ya da belki de henüz düşünmediğim başka bir seçenek var.

Gereksinimler:

  • Bant genişliği dağılımı bile bir zorunluluktur. Oldukça güçlü bir sunucum var, bu yüzden ölçeklendirme bir seçenek değil. Daha fazla bant genişliği elde etmek için ölçeklendirmem gerekiyor.

  • Kısa URL'ler. Görüntülerimi sunmak için img.example.com gibi bir alt alan adı ayarlamayacağım. example.com/image.jpg şimdi nasıl ve nasıl kalmasını istiyorum. Ama başka yolu yoksa, o zaman anlıyorum.

  • İstek işleme clostest sunucusu gerçekten güzel olurdu, ama bir zorunluluk değil. Akılda tutulması gereken bir şey.

Yük dengelemesi için HAProxy:

  • Zaten HAProxy kullandığım için bunu yapmak çok kolay olurdu. Ancak, bant genişliği dağıtılırken sorun olduğunu düşünüyorum. Bu konuda yanlış olabilir, ancak HAProxy, sunucunun işlediği ve daha sonra istemciye HAProxy aracılığıyla geri gönderdiği bir sunucuya istek göndermiyor mu? Böylece, tüm trafik yük dengeleyici üzerinden geri döner ve tüm sunucular birleştirildiği kadar bant genişliği kullanmasına neden olur.

DNS Turu Robin:

  • Bu benim en iyi seçeneğim olabilir. Web sitesini birden çok sunucuda çoğaltın ve şimdi ne yaptığımı yapın. Dezavantajı, bir sunucu çökerse, istemciler yine de ona gönderilir. Ayrıca siteyi birden çok sunucu arasında çoğaltmam gerekir. Ben tür statik dosyaları dışında her şeyi işleyen bir ana sunucu ve daha sonra statik dosya sunucuları bir çift umuyordum. Bunun bir çeşit 'fakir adamın yük dengelemesi' olduğunu da okudum ve biraz daha sofistike bir şeye sahip olmak güzel olurdu.

Doğrudan Sunucu Dönüşü:

  • Gerçekten karmaşık görünüyor, ancak iyi bir seçenek olabilir. Yine de belirli URL'leri belirli sunuculara gönderebilir miyim? Şu anda HAProxy'de olduğu gibi, doğru dosya uzantısında biten her URL Lighttpd'ye gönderilirken, diğer uzantılar Apache'ye gönderilir. Bu yüzden benzer bir şeye ihtiyacım var. Gibi, tüm php istekleri dengeleme yazılımı çalıştıran aynı sunucu tarafından işlenirken, tüm jpg istekleri birden çok sunucuya gönderilir.

İdeal olarak, HAProxy Direct Server Return'i destekliyorsa sorunum çözülecektir. Ayrıca bir CDN kullanmak istemiyorum, çünkü gerçekten pahalılar ve bu sadece bir yan proje.

Sorunumu anlıyor musun? Bir şeyi doğru bir şekilde açıklamamışsam veya daha fazla bilgiye ihtiyacınız varsa bana bildirin.


1
Bu Imgur ve son zamanlarda 40 milyon dolar topladı. : O
L1th1um

Yanıtlar:


3

Uygulama için istek / yanıt döngünüzün bir resmini çizin ve darboğazı izole edin. Yükü birçok uygulama sunucusuna dağıtan tek bir proxy'nin, tüm uygulama sunucularının toplam bant genişliğini gerektireceği doğrudur. Klasik çözüm RR DNS'dir. Google, Yahoo ve Amazon bu tekniği kısa bir TTL ile kullanıyor. Bir süre önce biraz araştırma yaptım ve bulgularımı belgeledim .

Başka bir çözüm, gerçek IP adreslerine sahip birden çok uygulama sunucusu arasında istekleri dengelemek için sanal IP adresleme kullanarak süslü pantolon kurumsal yük dengeleme çözümü kullanmaktır. Netscaler ve Stonesoft ürünleriyle çalıştım. Her ikisi de iyi bir performans sergiliyor, ancak korkunç bir özdeyişe sahip ve oldukça karmaşık.


Çok teşekkür ederim. Anket sonuçlarınız çok yardımcı oldu. Sonunda geleceğim çözüm bence. Ancak, "İyi bir araştırmacı gibi, yeterli veri elde edene kadar hareket etmiyorum." :)
Alan

İçgörü için teşekkürler. Maalesef ironik bir şekilde bulgularınızla olan bağlantı kopmuş gibi görünüyor, düzeltebilir misiniz?
TCB13

3

Bazı cevaplar:

  • Evet, HTTP düzeyindeki bir proxy olarak çalıştığı için tüm trafik HAProxy üzerinden geçer. HAProxy, birden fazla arka uç sunucuyu dengeleyen ayrı bir sunucuya kurulsa bile bu durum aynı olacaktır. Barındırma sağlayıcınız yalnızca 100MBit ağ bağlantı noktaları sağlıyorsa ve zaten 100MBit zorlarsanız, bir sorununuz vardır.
  • Alanla ilgili olarak, en uygun şey web uygulamanızdan farklı bir alandan görüntüler sunmaktır - bir alt alan adı, farklı bir alan değil, böylece resim isteklerinde çerezler gönderilmez. Steve Souders orijinal çalışmasına veya Stack Overflow'daki uygulamaya bakın . Kısa URL'ler sizin için çok önemliyse, belki de en iyi şey web uygulamasını ana URL'den kaldırmak, yani dosya yönetimi uygulamasını login.sitename.com'a taşımak olabilir.

Resim isteklerinde kimlik doğrulamaya mı ihtiyacınız var? Değilse, Amazon S3 gibi bir şey kullanmaya ne dersiniz? Büyük ölçüde ölçeklenebilir ve veri aktarım maliyeti oldukça ucuzdur. Bu durumda Amazon S3 grup ana bilgisayar adı için DNS CNAME olarak i.sitename.com gibi bir şey kullanırdım, bkz. Amazonlar belgeleri . AFAIK, kök etki alanı adını (sitename.com) CNAME olarak kullanamazsınız, bu nedenle bunun için i.sitename.com gibi bir alt etki alanı kullanmanız gerekir.

Ayrıca resimlerinizi birden çok sunucuda karma yapabilirsiniz. Yani login.sitename.com ve a.sitename.com gibi bir DNS yapısı oluşturuyorsunuz; b.sitename.com; c.sitename.com ve cetera. "A." ve B." vb sunucular sadece görüntüler içeren bir dosya sistemi ve hafif bir HTTP sunucusu içerir (zaten Lighttpd kullanıyorsunuz, bu yüzden kullanmaya devam edin. Gelecek bir proje için, nginx'e daha iyi bir yedek olarak bakmayı öneriyorum.) Bir kullanıcı yüklediğinde bir resim, benzersiz bir tanımlayıcının karmasını, belki onun kullanıcı adını, belki de dosya adını veya birden çok tanımlayıcının bir kombinasyonunu oluşturursunuz . Bu karmadan, görüntüyü hangi sunucuda depolayacağınızı belirleyebilirsiniz.

Düzenleme Karma zaten tartışılmış olduğunu görmeliydim. Aslında burada önerdiğim şey, ana bilgisayar adında karma kullanmak, ağ trafiğini birden çok ana bilgisayara eşit olarak yaymaktır.

Bunun için ne kadar ucuza ihtiyacınız olduğunu bilmiyorum - ancak 100MBit ağ trafiğini zorladığınızda, "ucuz ve iyi" hızla bir yanılsama oluyor. Belki önce iyi bir iş modeli edinmeye, tekrar eden gelir sağlayan bir şeye bakmalı ve daha sonra uygun teknolojiyi uygulamalısınız?


1

HAProxy'nin diğer uygulamalarınızla aynı sunucuda olduğunu varsayıyorum? İstekleri çalıştırmak ve bir sunucuya normal istekleri ve başka bir sunucuya görüntü istekleri göndermek için HAProxy'yi başka bir sisteme ayırabilirsiniz. Sorun şu ki, tüm istekler hala bir kutuya gidiyor ve bant genişliğini doyuruyorsanız, bu size çok yardımcı olmayabilir.

Kısa URL'lerin önemli olduğunu söylüyorsunuz. Neden? Görüntüleri "example.com" dan "i.example.com" a değiştirmek gerçekten büyük bir fırsat mı? "İ" yi Lighttpd ile kendi sunucusunda kendi IP'sine ayarlayabilir ve HAProxy'yi tamamen atlatarak verim sorununuzu çözebilirsiniz. Ayrıca, farklı etki alanı adları olduklarını ve daha fazla eşzamanlı bağlantı açabildiklerinden, aynı anda daha fazla isteğin açılmasına izin veren web tarayıcısının avantajlarından da yararlanabilirsiniz. Tek "i" sunucusu doymuşsa, başka bir tane eklemek için DNS round-robin kullanabilirsiniz. Umarım o zamana kadar daha iyi bir çözüm uygulamak için yeterli gelir elde edersiniz.


Evet, HAProxy aynı sunucuda - şimdiye kadar sadece bir tane var. Başka bir sunucuya geçsem bile, yukarıda açıkladığım gibi tüm veriler HAProxy ile hala sunucudan geçmez mi? Kısa URL'ler önemlidir, çünkü bu sitenin amacıdır. ImageShack ve TinyPic arasında bir geçiş. URL ne kadar uzun olursa, sitemin puanı o kadar az olur. Ama dediğim gibi, uygulanabilir olan tek seçenek bir alt alan adı ayarlamaksa, bunu yapmak zorundayım. Gerçekten de yapmamayı tercih ederim.
Alan

1

Barındırma sağlayıcınız yük dengeleme hizmetleri sunuyor mu? Bence en iyi çözüm bu.

Bunu yapmanın başka bir yolu, ancak test edilmesi gerekiyor, istekleri yeniden yazmak (hafif veya apache). Örneğin: example.com/file.html apache'de kalır ve example.com/image.jpg i.example.com/image.jpg adresine yönlendirir. Tüm istekler apache üzerinden yönetilecek, ancak yanıtlar (yukarı akış bant genişliği) lighttpd sunucusuna gidecek. Alan kullanıcı için şeffaftır. Yine de apache'nin tüm istekleri işleyip işleyemeyeceğini test etmelisiniz ya da lighttpd'nin bu işi yapmasına izin verin.

Haklısın tüm veriler HAProxy'den geçer, böylece (bildiğim kadarıyla) doğrudan sunucu dönüşü yapamazsın.

GÜNCELLEME

HAproxy belgelerine baktığımda " redir " parametresini buldum. Apache yeniden yazma gibi çalışıp çalışmadığını bilmiyorum ama yararlı olabilir. Belgeler diyor ki:

Ana kullanım, istemcilerin bunlara doğrudan bağlanmasını sağlayarak statik sunucular için bant genişliğini artırmaktır.

Belki sizin durumunuz için işe yarar.


Hey, cevap için teşekkürler. Aslında bunu zaten denedim ve teoride olduğu gibi pratikte de işe yaramıyor. Bunun nedeni, Apache'nin tüm istekleri yerine getirmesidir, bu nedenle bir kullanıcı bir görüntüye her bastığında Apache yumurtlanır, url'ye bakar ve sonra onu hafifçe gönderir. Hangi farklı değil sadece Apache görüntüyü ilk etapta işlemek zorunda. Ev sahibim tarafından sağlanan bir yük dengeleyicinin en iyi seçenek olduğunu kabul ediyorum, ancak aynı zamanda en pahalı olanlardan biri. Eşzamanlı bağlantı başına ücret alıyorlar ve yüzlerce tane alıyorum.
Alan

Hafif sunucunun yanıtı doğrudan kendi bant genişliğini tüketen istemciye gönderme biçiminde farklıdır. Sorun, Apache sunucusunun birçok isteği ele almasıdır. Cevabımın güncellemesini kontrol et, başka bir çözüm buldum.
hdanniel

1

Herhangi bir büyüklükteki görüntü kümesinde, ad çakışmalarıyla oldukça hızlı bir şekilde karşılaşacağınız için görüntüleri orijinal dosya adlarına göre saklamadığınızı varsayıyorum.

Bu tür sorunlarla ilgilenen birçok uygulama dosyanın karmasını ve bu karmayı temel alan bir dizin yapısını kullanır. Dizin yapısı, dizin yolunun karmanın ilk iki karakteri olduğu, 2. düzey dizinin ise karmadaki sonraki iki karakter olduğu aşağıdaki gibi görünür.

/image root/AA/AA/images  
/image root/AA/AB/images

Buradaki fayda, karma işlemlerin dosyaların dağıtımını oldukça eşit tutması ve size birden fazla sunucuya bölünmesi kolay bir ad alanı sağlamasıdır. Temel olarak karma alanın bölümlerini farklı sunuculardan sunarsınız ve ölçeklendirirken bunu gerektiği gibi alt bölümlere ayırabilirsiniz.

Dezavantajı, hashes mükemmel değildir ve çarpışmalar olabilir. Bunun nasıl ele alındığından emin değilim. Bu sizin açınızdan biraz araştırma gerektirebilir. Proxy'deki bir yeniden yazma kuralının A3A8BBC83261.jpg adlı bir karma değerini alıp http://img3.domain.com/A3/A8/BBC83261.jpg adresine yeniden yazabilmesi gerektiğini düşünüyorum . Yine de kısa bir url olduğunu düşünmeyebilirsiniz.


Evet, görüntüleri tam olarak böyle saklıyorum. Ancak, sorun depolama ile değil, bant genişliği dağılımıyla ilgili.
Alan

Ancak AA'yı 33'ten bir sunucuya ve 34'den 99'a başka bir sunucuda depolarsanız, depolama sorununu dengelemekle kalmaz, aynı zamanda bant genişliği dağıtımını da dengelersiniz.
3dinfluence

0

Gönderinizde DNS round robbin'in en iyi seçenek olabileceğini düşündünüz, ancak tek bir sunucunun başarısız olmasından endişe ettiniz ...

Bu durumda JH Software'den Simple Failover'a bir göz atın. Geçmişte kullandım ve çok iyi çalışıyor.

http://www.simplefailover.com

Temel olarak sunucularınızı izler ve bir tanesinin aşağı gittiğini gördüğünde, ölü sunucuyu döndürme işleminden çıkarmak için DNS'yi hızlı bir şekilde yeniden yazar.

İşte web sitelerinden bir pasaj:

Basit Yük Devretme, hangilerinin hangilerinin hangilerinin kapalı olduğunu bulmak için sunucularınızı sürekli olarak izler ve daha sonra etki alanı adınızın her zaman işlevsel bir sunucuyu işaret etmesi için DNS kayıtlarınızı buna göre dinamik olarak güncelleştirir.

Web sunucuları (HTTP), posta sunucuları (SMTP, IMAP, POP3), FTP sunucuları ve hemen hemen tüm diğer TCP / IP tabanlı sunucu türleriyle çalışır.

Daha önce de belirtildiği gibi, geçmişte hem web siteleri hem de posta sunucuları için kullandım. Oldukça iyi performans gösterdi. Yük devretme çoğu durumda oldukça hızlıydı (2-5dk tahmin) ve neredeyse herkesin 15 dakikadan az bir sürede başarısız olduğunu söyleyebilirim.

Mutlaka MÜKEMMEL değil ... ama kesinlikle hızlı ve kolay.

NOT: Bu bir Windows ürünüdür. Linux sürümüne sahip olup olmadıklarından emin değilim, ancak DNS tabanlı olduğundan istediğiniz herhangi bir sunucuda başarısız olabilirsiniz.

Bizim durumumuzda, sadece bir XP makinesine attık, makineye gece bir kez yeniden başlamasını söyledik ve yıllarca iyi çalıştı.

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.