Bütçede Apache yükü dengeleme?

Milyonlarca kullanıcıya kabarma hızı sunmak yerine yük dengeleme yerine kullanıcıları mutlu etmek için kullanılabilirliği ve artıklığı sağlamak için yük dengeleme kavramı etrafında başımı kurmaya çalışıyorum.

Bütçemiz var ve bol miktarda bilginin olduğu şeylere sadık kalmaya çalışıyoruz, bu yüzden Ubuntu VPS'lerde Apache'yi çalıştırmak, bazı ünlü arama motorları bizi elde edene kadar strateji gibi görünüyor ( Cumartesi ironisi dahil, lütfen unutmayın ).

En azından benim için, farklı çözümlerin eksiksiz bir ormanı. Apaches kendi mod_proxy ve HAproxy hızlı bir google arama ile bulduğumuz iki, ancak yük dengeleme sıfır deneyime sahip, bizim durumumuz için neyin uygun olacağını ya da çözmek için bir çözüm seçerken nelere dikkat edeceğimizi bilmiyorum kullanılabilirlik kaygıları.

Bizim için en iyi seçenek nedir? Bütçelerimizde kalırken kullanılabilirliği artırmak için ne yapmalıyız?

Kullandığım ve VPS ile kolayca uygulanabilen çözüm şudur:

• DNS, 6 farklı geçerli IP adresine yuvarlanır (sp?).
• Aynı yapılandırmaya sahip 3 yük dengeleyicim var ve 6 ip adresini eşit olarak dağıtmak için corosync / pacemaker kullanıyorum (böylece her makine 2 adres alır).
• Yük dengeleyicilerin her birinin bir nginx + vernik konfigürasyonu vardır. Nginx bağlantıları almak, yeniden yazma ve bazı statik sunumlar yapmak ve yük dengeleme ve önbelleğe alma işlemlerini Varnish'e aktarmakla ilgilenir.

Bu kemer önyargılı görüşüme göre aşağıdaki avantajlara sahiptir:

1. corosync / pacemaker, LB'den birinin arızalanması durumunda ip adreslerini yeniden dağıtacaktır.
2. nginx, önbelleği (büyük videolar, ses veya büyük dosyalar) kullanmadan SSL, belirli dosya türlerini doğrudan dosya sisteminden veya NFS'den sunmak için kullanılabilir.
3. Vernik ağırlık, arka uç sağlık kontrolü destekleyen çok iyi bir yük dengeleyicidir ve ters proxy olarak olağanüstü bir iş çıkarır.
4. Trafiği ele almak için daha fazla LB'ye ihtiyaç duyulması durumunda, kümeye daha fazla makine eklemeniz yeterlidir; IP adresleri tüm makineler arasında yeniden dengelenir. Hatta bunu otomatik olarak da yapabilirsiniz (yük dengeleyicileri ekleyip çıkararak). Bu yüzden büyüme için biraz alan bırakmak için 3 makine için 6 ips kullanıyorum.

Sizin durumunuzda, fiziksel olarak ayrılmış VPS'lere sahip olmak iyi bir fikirdir, ancak ip paylaşımını daha zor hale getirir. Amaç, hataya dayanıklı, yedekli bir sisteme ve yük dengeleme / HA ucu için tek bir arıza noktası ekleyerek (tüm trafiği almak için tek bir yük dengeleyici gibi) onu karıştırmak için bazı yapılandırmalara sahip olmaktır.

Ayrıca apache'yi sorduğunuzu da biliyorum, ancak o günlerde işe daha uygun belirli araçlarımız var (nginx ve vernik gibi). Uygulamaları arka uçta çalıştırmak ve diğer araçları kullanarak sunmak için apache bırakın (apache'nin iyi yük dengeleme veya ters proxy yapamaması değil, bu sadece işin farklı bölümlerini daha fazla hizmete boşaltmakla ilgilidir, böylece her bir parça iyi yapabilir payı).

HAproxy iyi bir çözümdür. Yapılandırma oldukça basittir.

En az 2 VPS'nin önünde oturmak için başka bir VPS örneğine ihtiyacınız olacak. Bu nedenle yük dengeleme / arıza için en az 3 VPS gerekir

Düşünülmesi gereken birkaç şey:

1. SSL sonlandırma. HTTPS: // kullanırsanız bu bağlantının yük dengeleyicide sonlanması gerekir, yük dengeleyicinin arkasında şifrelenmemiş bir bağlantı üzerinden tüm trafiği geçirmesi gerekir.

2. Dosya depolama. Bir kullanıcı bir resim yüklerse nereye gider? Sadece bir makinede mi oturuyor? Dosyaları makineler arasında anında paylaşmak için bir yere ihtiyacınız var - tüm statik dosyalarınızı saklamak için Amazon'un S3 hizmetini kullanabilirsiniz veya dosya sunucusu olarak hareket edecek başka bir VPS'ye sahip olabilirsiniz, ancak gereksiz ve inanılmaz derecede ucuz olduğu için S3'ü öneriyorum.

3. oturum bilgisi. yük dengeleyici yapılandırmanızdaki her makinenin kullanıcının oturum bilgilerine erişebilmesi gerekir, çünkü hangi makineye vuracaklarını asla bilemezsiniz.

4. db - ayrı bir db sunucunuz var mı? şu anda sadece bir makineniz varsa, yeni makinenizin db sunucusuna erişebileceğinden nasıl emin olacaksınız - ve ayrı bir VPS db sunucusu ise, bu ne kadar gereksizdir. Yüksek kullanılabilirlikli web ön uçlarına ve bir db sunucusu ile tek bir hata noktasına sahip olmak mantıklı değildir, şimdi db çoğaltma ve köle tanıtımını da düşünmeniz gerekir.

Bu yüzden ayakkabılarına girdim, gerçek bir operasyon için günde birkaç yüz vuruş yapan bir web sitesi ile ilgili sorun bu. Hızlı karmaşıklaşır. Bu düşünce için yiyecek verdi umut :)

Benim oyum yük dengeleyici olarak Linux Sanal Sunucusu için. Bu, LVS direktörünü bir darboğazın yanı sıra tek bir başarısızlık noktası haline getirir, ancak

1. Darboğaz, benim deneyimime göre, bir sorun değildir; LVS yönlendirme adımı katman-3'tür ve son derece (hesaplamalı olarak) ucuzdur.
2. Tek başarısızlık noktası, ikisi Linux HA tarafından kontrol edilen ikinci bir yönetmenle ele alınmalıdır .

İlk yönetmenin ilk LVS düğümü ile aynı makinede ve ikinci yönetmenin ikinci LVS düğümü ile aynı makinede olmasıyla maliyet azaltılabilir. Üçüncü ve sonraki düğümler saf düğümlerdir, LVS veya HA etkisi yoktur.

Bu, yönlendirmenin uygulama katmanının altında gerçekleştiği için, istediğiniz herhangi bir web sunucusu yazılımını çalıştırmanıza da izin verir.

Bu zincire ne dersin?

round robin dns> her iki makinede haproxy> statik dosyaları ayırmak için nginx> apache

Muhtemelen her zaman cevaplamak için ucarp veya kalp atışı kullanın. SSL'ye de ihtiyacınız varsa, stunnel haksinin önünde oturur

Uygun kümeleme yazılımını kullanmayı düşünebilirsiniz. RedHat (veya CentOS) Cluster Suite veya Oracle'ın ClusterWare'i . Bunlar, aktif-pasif kümeleri kurmak için kullanılabilir ve hizmetleri yeniden başlatmak için kullanılabilir ve ciddi sorunlar olduğunda düğümler arasında başarısız olur. Bu aslında aradığınız şey.

Tüm bu küme çözümleri ilgili işletim sistemi lisanslarına dahil edilmiştir, bu nedenle muhtemelen maliyetten tasarruf edersiniz. Bir tür paylaşılan depolama alanı gerektirir - bir NFS yuvası veya kümelenmiş bir dosya sistemine sahip her iki düğümün eriştiği fiziksel disk. İkincisine örnek olarak, OCFS2 veya GFS ile biçimlendirilmiş birden çok ana bilgisayar erişimine izin verilen SAN diskleri verilebilir . Bunun için VMWare paylaşılan disklerini kullanabileceğinizi düşünüyorum .

Küme yazılımı, düğümlerde her zaman veya yalnızca bu düğüm 'etkin' olduğunda çalışan 'hizmetleri' tanımlamak için kullanılır. Düğümler kalp atışlarıyla iletişim kurar ve ayrıca bu hizmetleri izler. Arıza fark ederse bunları yeniden başlatabilir ve düzeltilemezlerse yeniden başlatabilirler.

Temel olarak, trafiğin yönlendirileceği tek bir 'paylaşılan' IP adresi yapılandırırsınız. Daha sonra apache ve diğer gerekli hizmetler de tanımlanabilir ve yalnızca etkin sunucuda çalıştırılabilir. Paylaşılan disk, tüm web içeriğiniz, yüklenen dosyalarınız ve apache yapılandırma dizinleriniz için kullanılır. (httpd.conf vb. ile)

Deneyimlerime göre, bu inanılmaz derecede iyi çalışıyor.

• DNS round robin veya başka bir tek hata noktası yük dengeleyicisine gerek yoktur - her şey bir IP / FQDN'ye çarpar.
• Kullanıcı tarafından yüklenen dosyalar bu paylaşılan depolama alanına gider ve bu nedenle makinenizin başarısız olup olmadığı umurumda değildir.
• Geliştiriciler, sıfır ek eğitim ile bu tek IP / FQDN'ye içerik yükler ve başarısız olursa her zaman günceldir.
• Yönetici çevrimdışı makineyi alabilir, halkı ondan çıkarabilir, yeniden başlatabilir, vb. Ardından etkin düğümü devre dışı bırakabilir. Yükseltme yapmak minimum kesinti süresi gerektirir.
• Artık güncel olmayan düğüm bir süreliğine işlenmeden tutulabilir ve bu da bir geri dönüşü aynı derecede kolay bir işlem haline getirir. (VMWare anlık görüntülerinden daha hızlı)
• Bir yönetici çevrimdışı kutusunda değişiklik yapmayı unuttuğu için, yük devretme sırasında garip bir şey olmaması için Apache'nin yapılandırmasındaki değişiklikler paylaşılır.

--Christopher Karel

Optimal yük dengeleme çok pahalı ve karmaşık olabilir. Temel yük dengeleme, her sunucunun her zaman kabaca aynı sayıda isabet verdiğinden emin olmalıdır.

En basit yük dengeleme yöntemi, DNS'de birden fazla A kaydı sağlamaktır. Varsayılan olarak IP adresi bir yuvarlak robin yöntemiyle yapılandırılır. Bu, kullanıcıların sunucular arasında nispeten eşit olarak dağıtılmasına neden olur. Bu durum vatansız siteler için iyi çalışır. Durum bilgisi olan bir siteniz olduğunda biraz daha karmaşık bir yöntem gerekir.

Durum bilgisi olan gereksinimleri işlemek için yönlendirmeleri kullanabilirsiniz. Her web sunucusuna www1, www2, www3 vb. Gibi alternatif bir adres verin. İlk www bağlantısını ana bilgisayarın alternatif adresine yeniden yönlendirin. Bu şekilde yer imi sorunlarıyla karşılaşabilirsiniz, ancak bunlar sunucular arasında eşit olarak dağıtılmalıdır.

Alternatif olarak, durumlu oturumu hangi sunucunun işlediğini belirtmek için farklı bir yol kullanılması, ana makineyi orijinal sunucuya geçiren proxy oturumlarına izin verir. Hatalı bir sunucu için oturum başarısız olan sunucudan devralınan sunucuya ulaştığında bu sorun olabilir. Bununla birlikte, kümelenme yazılımını engelleme durumu zaten eksik olacaktır. Tarayıcı önbelleği nedeniyle, sunucuları değiştiren çok sayıda oturum yaşamayabilirsiniz.

Yük devretme, sunucuyu, başarısız bir sunucunun IP adresini alacak şekilde yapılandırmak suretiyle gerçekleştirilebilir. Bu, bir sunucu arızalanırsa çalışmama süresini en aza indirir. Kümeleme yazılımı olmadan, bir sunucu başarısız olursa durum bilgisi olan oturumlar kaybolur.

Yük devretme olmadan kullanıcılar, tarayıcıları bir sonraki IP adresine geçene kadar bir gecikme yaşayacaklardır.

Durum bilgisi olan oturumlar yerine Huzurlu hizmetlerin kullanılması, ön uçtaki kümeleme sorunlarını ortadan kaldırmalıdır. Depolama tarafındaki kümeleme sorunları hala geçerli olacaktır.

Sunucuların önündeki yük dengeleyicilerle bile, büyük olasılıkla önlerinde yuvarlatılmış DNS olacaktır. Bu, tüm yük dengeleyicilerinizin kullanılmasını sağlayacaktır. Ek karmaşıklık ve başka bir arıza noktası ile tasarımınıza başka bir katman ekleyecekler. Ancak, bazı güvenlik özellikleri sağlayabilirler.

En iyi çözüm ilgili gereksinimlere bağlı olacaktır.

Görüntüler, CSS dosyaları ve diğer statik içerik gibi içerikleri sunmak için görüntü sunucularını uygulamak uygulama sunucularındaki yükü hafifletebilir.

Genellikle bir çift özdeş OpenBSD makinesi kullanıyorum:

• Yük dengeleme, web sunucusu izleme ve başarısız bir web sunucusunun işlenmesi için RelayD kullanın
• Yük dengeleyicilerin yüksek kullanılabilirliği için CARP kullanın.

OpenBSD hafif, kararlı ve oldukça güvenlidir - Ağ hizmetleri için mükemmeldir.

• http://www.openbsd.org - Ana site
• http://www.openbsd.org/faq/pf/carp.html - Sazan belgeleri
• https://calomel.org/relayd.html - RelayD hakkında iyi bir bilgi kümesi

Başlamak için bir layer3 kurulumu öneririm. Güvenlik duvarı (PF) kurulumunda komplikasyonları önler. Arka uç web sunucularının izlenmesiyle basit bir röle yük dengeleyicisinin kurulumunu gösteren bir örnek /etc/relayd.conf dosyası:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Ec2'yi cloudfoundry ile ya da belki bir elastik fasulye sapı ya da sadece bir düşünceyi otomatik olarak ölçeklendiren düz eski bir AWS ile verdiniz . Bunu kullanıyorum ve oldukça iyi ölçekleniyor ve elastik olmak insan müdahalesi olmadan ölçeklenebilir / küçülebilir.

Yük dengeleme konusunda sıfır deneyime sahip olduğunuzu söylediğinizde, kalkmak ve koşmak için minimal beyin "kızartma" gerektirdiklerinden bu seçenekleri öneririm.

Zamanınızı daha iyi kullanmak olabilir.