Ölçeklenebilirlik - bir cihazın kapasitesini artırma yeteneği
yetenekler
fonksiyonel blokların sayısını artırarak,
birini gerçekleştirmek ve
aynı görevler.
sözlük.ru
Genellikle ölçeklendirmeyi düşünmeye başlarlar
Sunucu işe bağlı değil. tam olarak ne yapmıyor
başa çıkmak? Herhangi bir web sunucusunun çalışması genel olarak ana konuya iner.
bilgisayarların işgali - veri işleme. HTTP (veya başka herhangi bir) isteğine yanıt
bazı veriler üzerinde bazı işlemler gerçekleştirmeyi içerir. Sırasıyla,
iki ana varlığımız var - bu veriler (hacmiyle karakterize edilir) ve
hesaplamalar (karmaşıklık ile karakterize edilir). Sunucu onun üstesinden gelemeyebilir.
büyük miktarda veri nedeniyle çalışma (fiziksel olarak sığmayabilirler)
sunucu) veya büyük bir hesaplama yükü nedeniyle. burada konuşuyor
elbette, toplam yük hakkında - bir isteği işlemenin karmaşıklığı
küçük, ancak çok sayıda sunucuyu "doldurabilir".
Ağırlıklı olarak bir örnekle ölçeklendirmeden bahsedeceğiz
tipik bir büyüyen web projesidir, ancak burada açıklanan ilkeler aynı zamanda
diğer uygulama alanları. Önce projenin mimarisine bakarız ve basit bir
kurucu parçalarının birkaç sunucuya dağıtılması ve sonra hakkında konuşacağız
ölçeklendirme bilgi işlem ve veri.
Tipik site mimarisi
Tipik bir web sitesinin ömrü çok basit bir mimariyle başlar
- bu bir web sunucusudur (genellikle Apache rolünü yerine getirir),
HTTP istekleri sunmanın tüm işlerini yürüten,
ziyaretçilerden geliyor. Müşterilere sözde "statik" verir, sonra
sunucu diskinde işlem gerektirmeyen dosyalar var: resimler (gif,
jpg, png), stil sayfaları (css), istemci komut dosyaları (js, swf). aynı sunucu
hesaplama gerektiren sorgulara yanıt verir - genellikle bu oluşumdur
html sayfaları, bazen görüntüler ve diğer belgeler anında oluşturulsa da.
Çoğu zaman, bu tür isteklere verilen yanıtlar php ile yazılmış betikler tarafından oluşturulur.
perl veya diğer diller.
Bu kadar basit bir çalışma planının dezavantajı, farklı
isteklerin doğası (diskten dosyaların iadesi ve komut dosyalarının hesaplamalı çalışması)
aynı web sunucusu tarafından işlenir. Hesaplamalı sorgular şunları gerektirir:
sunucu belleğinde çok fazla bilgi tutun (betik dili yorumlayıcısı,
komut dosyalarının kendileri, birlikte çalıştıkları veriler) ve çok şey alabilir
bilgi işlem kaynakları. Aksine, istatistik yayınlamak çok az kaynak gerektirir
işlemci, ancak istemcinin düşük olması durumunda uzun zaman alabilir.
iletişim hızı. Apache sunucusunun dahili bileşenleri, her birinin
bağlantı ayrı bir işlem tarafından gerçekleştirilir. Bu komut dosyası için kullanışlıdır.
ancak, basit istekleri işlemek için ideal değildir. Görünüşe göre ağır (
komut dosyaları ve diğer veriler) Apache süreçleri beklemek için çok zaman harcar (ilk olarak
istek, ardından bir yanıt gönderirken), sunucu belleğini boşa harcama.
Bu sorunun çözümü, işleme işinin dağıtılmasıdır.
iki farklı program arasındaki istekler - yani. ön yüze bölme ve
arka uç. Hafif bir ön uç sunucusu, statik döndürme görevlerini gerçekleştirir ve gerisini
istekler (proxy'ler), oluşumun gerçekleştirildiği arka uca yönlendirilir
sayfalar. Yavaş istemcileri beklemek de ön uç tarafından devralınır ve eğer kullanırsa
çoğullama (bir işlem birkaç istemciye hizmet verdiğinde - bu nedenle
çalışmak, örneğin, nginx veya lighttpd), sonra neredeyse hiçbir şey beklemeyin
maliyetler.
Sitenin diğer bileşenlerinden, veritabanına not edilmelidir.
genellikle sistemin ana verilerini depolar - burada en popüler
ücretsiz DBMS MySQL ve PostgreSQL. Depolama genellikle ayrıdır
resim içeren ikili dosyalar (örneğin, makaleler için resimler
site, avatarlar ve kullanıcıların fotoğrafları) veya diğer dosyalar.
Böylece, aşağıdakilerden oluşan bir mimari diyagram elde ettik.
birkaç bileşen.
Genellikle sitenin ömrünün başlangıcında, mimarinin tüm bileşenleri
aynı sunucuda bulunur. Yükle baş edemezse, o zaman
basit bir çözüm var - en kolay ayrılan parçaları diğerine taşımak
sunucu. Bir veritabanına başlamanın en kolay yolu, onu ayrı bir sunucuya taşımak ve
komut dosyalarındaki erişim ayrıntılarını değiştirin. Bu arada, bu noktada karşı karşıyayız
uygun kod mimarisinin önemi. Bir veritabanı ile çalışıyorsanız
tüm site için ortak olan ayrı bir modüle taşındı - ardından parametreleri düzeltin
bağlantılar basit olacaktır.
Bileşenleri daha fazla ayırmanın yolları da açıktır - örneğin, ön ucu ayrı bir sunucuya taşıyabilirsiniz. Ama genellikle ön uç
az sistem kaynağı gerektirir ve bu aşamada kaldırılması önemli olmayacaktır
performans kazancı. Çoğu zaman, site performansa dayanır.
komut dosyaları - yanıt (html sayfası) oluşturmak çok uzun sürüyor.
Bu nedenle, sonraki adım genellikle arka uç sunucusunu ölçeklendirmektir.
Hesaplama dağılımı
Büyüyen bir site için tipik bir durum, veritabanının zaten
ayrı bir makineye taşındı, ön uç ve arka uç olarak bölünme tamamlandı,
ancak trafik artmaya devam ediyor ve arka ucun işlemek için zamanı yok
istekler. Bu, hesaplamaları birkaç taneye dağıtmamız gerektiği anlamına gelir.
sunucular. Yapması kolay - sadece ikinci bir sunucu satın alın ve kurun
arka ucun çalışması için gerekli programlara ve komut dosyalarına sahiptir.
Bundan sonra, kullanıcı isteklerinin dağıtıldığından emin olmanız gerekir.
(dengeli) alınan sunucular arasında. Farklı dengeleme yolları hakkında
aşağıda tartışılacaktır, ancak şimdilik, ön ucun genellikle bunu yaptığını not ediyoruz,
istekleri arasında eşit olarak dağıtacak şekilde yapılandırılmıştır.
sunucular.
Tüm arka uç sunucularının düzgün şekilde çalışabilmesi önemlidir.
sorgulamalara yanıt verin. Bu genellikle her birinin birlikte çalışmasını gerektirir
aynı gerçek veri seti. Tüm bilgileri tek bir dosyada saklarsak
veritabanı, DBMS'nin kendisi veri paylaşımı ve tutarlılığı sağlayacaktır.
Bazı veriler sunucuda yerel olarak depolanıyorsa (örneğin, php oturumları
istemci), o zaman onları paylaşılan bir depoya taşımayı veya daha fazlasını düşünmelisiniz.
istekleri dağıtmak için karmaşık algoritma.
Çalışmaları yalnızca birkaç sunucuya dağıtmakla kalmazsınız
komut dosyaları değil, aynı zamanda veritabanı tarafından gerçekleştirilen hesaplamalar. DBMS çok şey yaparsa
karmaşık sorgular, sunucu CPU zamanını alarak, birkaç tane oluşturabilirsiniz
veritabanının farklı sunuculardaki kopyaları. Bu, senkronizasyon sorununu gündeme getirir.
değişikliklerle ilgili veriler ve burada birkaç yaklaşım uygulanabilir.
- senkronizasyon uygulama düzeyinde. Bu durumda, bizim
komut dosyaları, değişiklikleri veritabanının tüm kopyalarına bağımsız olarak yazar (ve kendileri
verilerin doğruluğundan sorumludur). Bu en iyi seçenek değil çünkü
uygulamada özen gerektirir ve yüksek oranda hataya açıktır. - çoğaltma- yani, otomatik çoğaltma
bir sunucuda yapılan değişiklikler diğer tüm sunucularda. Genellikle ne zaman
Çoğaltma kullanılarak, değişiklikler her zaman aynı sunucuya yazılır - buna ana denir ve kopyaların geri kalanına bağımlı denir. Çoğu DBMS'de
çoğaltmayı organize etmek için yerleşik veya harici araçlar. Ayırt etmek
eşzamanlı çoğaltma - bu durumda veri değişikliği isteği bekleyecek,
veriler tüm sunuculara kopyalanana kadar ve ancak o zaman başarıyla tamamlanır - ve eşzamansız olarak - bu durumda, değişiklikler sunuculardan bağımlı sunuculara kopyalanır.
gecikme, ancak yazma isteği daha hızlı tamamlanır. - Çoklu masterçoğaltma. Bu yaklaşım benzer
bir önceki, ancak burada verileri değiştirmemeye atıfta bulunarak değiştirebiliriz.
belirli bir sunucuya, ancak veritabanının herhangi bir kopyasına. Aynı zamanda, değişiklikler
eşzamanlı veya eşzamansız olarak diğer kopyalara ulaşın. Bazen bu şema denir
"veritabanı kümesi" terimi.
Sistemi sunucular arasında dağıtmak için farklı seçenekler vardır.
Örneğin, bir veritabanı sunucumuz ve birkaç arka ucumuz olabilir (çok
tipik şema) veya tam tersi - bir arka uç ve birkaç veritabanı. Ya ölçeklersek
hem arka uç sunucusunu hem de veritabanını, ardından arka ucu ve veritabanının kopyasını birleştirebilirsiniz.
Bir araba. Her durumda, birden fazla örneğimiz olduğunda
herhangi bir sunucu, aralarında nasıl düzgün bir şekilde dağıtılacağı sorusu ortaya çıkar.
yük.
Dengeleme Yöntemleri
Her biri istekleri işleyebilen birkaç sunucu (herhangi bir amaç - http, veritabanı vb.) oluşturduğumuzu varsayalım. Önceki
işlerin aralarında nasıl dağıtılacağı, hangisinin hangisi olduğunu nasıl bulacağımız görevi ile karşı karşıyayız.
istek göndermek için sunucu? İstekleri dağıtmanın iki ana yolu vardır.
- Dengeleme düğümü. Bu durumda, müşteri bir istek gönderir
kendisi tarafından bilinen sabit sunucu ve isteği zaten birine yönlendiriyor
çalışan sunucular Tipik bir örnek, bir ön ucu ve birkaç
isteklerin proxy'lendiği arka uç sunucuları. Ancak, müşteri şunları yapabilir:
sistemimizin içinde olun - örneğin, bir komut dosyası bir istek gönderebilir
isteği DBMS sunucularından birine iletecek bir veritabanı proxy'si.
Dengeleme düğümünün kendisi hem ayrı bir sunucuda hem de bir sunucuda çalışabilir.
çalışan sunuculardan.Bu yaklaşımın avantajları şunlardır:
müşterinin sistemin iç yapısı hakkında - sayı hakkında hiçbir şey bilmesine gerek olmadığını
sunucular, adresleri ve özellikleri - tüm bu bilgiler yalnızca bilinir
dengeleyici. Ancak dezavantajı, dengeleme düğümünün tek bir düğüm olmasıdır.
sistem arıza noktası - başarısız olursa, tüm sistem
çalıştırılamaz. Ek olarak, ağır yük altında dengeleyici çalışmayı durdurabilir.
işleriyle başa çıkmak, bu nedenle bu yaklaşım her zaman geçerli değildir. - İstemci tarafı dengeleme. kaçınmak istiyorsak
tek hata noktası, bir alternatif var - sunucu seçimini emanet etmek
müşterinin kendisi. Bu durumda müşteri, şirketimizin iç yapısının farkında olmalıdır.
Hangi sunucuyla iletişim kurulacağını doğru seçebilmek için sistemler.
Kuşkusuz avantaj, bir başarısızlık noktasının olmamasıdır - eğer bunlardan biri
sunucular, istemci başkalarıyla iletişim kurabilecektir. Ancak bunun bedeli
müşteri mantığının karmaşıklığı ve daha az dengeleme esnekliği.
Tabii ki, bu yaklaşımların kombinasyonları da var. Örneğin,
DNS dengeleme gibi iyi bilinen bir yük dengeleme yöntemi,
sitenin IP adresini belirlerken, müşteriye verilir
birkaç özdeş sunucudan birinin adresi. Böylece, DNS şu şekilde davranır:
müşterinin "dağıtımı" aldığı dengeleme düğümünün rolü. Yine de
DNS sunucularının yapısı, bir arıza noktasının bulunmadığını varsayar.
çoğaltma - yani, iki yaklaşımın avantajları birleştirilir. Tabii ki, böyle
dengeleme yönteminin dezavantajları da vardır - örneğin, böyle bir sistemi dinamik olarak yapmak zordur
yeniden inşa et.
Site ile çalışmak genellikle tek bir istekle sınırlı değildir.
Bu nedenle, tasarım yaparken sıralı isteklerin gerçekleştirilip gerçekleştirilemeyeceğini anlamak önemlidir.
istemcinin farklı sunucular tarafından doğru bir şekilde ele alınması veya istemcinin
siteyle çalışırken bir sunucuya bağlı. Bu özellikle önemlidir, eğer
Site, kullanıcının oturumuyla ilgili geçici bilgileri kaydeder (bu
durumda, ücretsiz dağıtım da mümkündür - ancak o zaman depolamak gerekir
tüm sunucular için ortak depolamada oturum). Ziyaretçiyi şuraya bağla
belirli bir sunucu, IP adresini kullanabilirsiniz (ancak değişebilir),
veya çerez (sunucu tanımlayıcısının önceden yazıldığı) veya hatta
sadece istenen etki alanına yönlendirerek.
Öte yandan, bilgi işlem sunucuları eşit olmayabilir.
Bazı durumlarda bunun tam tersini yapmakta fayda var, bunun için ayrı bir sunucu tahsis edin.
tek tip istekleri işleme - ve dikey bir ayrım elde etme
fonksiyonlar. Daha sonra istemci veya dengeleme düğümü, sunucuyu seçecektir.
alınan talebin türüne bağlı olarak. Bu yaklaşım, ayırmayı mümkün kılar.
diğerlerinden önemli (veya tam tersi, kritik değil, ağır) istekler.
Veri dağıtımı
Hesaplamaları nasıl dağıtacağımızı öğrendik, bu yüzden büyük bir
Katılım bizim için sorun değil. Ancak, veri hacimleri büyümeye devam ediyor,
bunları depolamak ve işlemek giderek daha zor hale geliyor - bu da inşa etme zamanının geldiği anlamına geliyor
dağıtılmış veri depolama Bu durumda, artık bir tane veya
veritabanının tam bir kopyasını içeren birden çok sunucu. Bunun yerine, veri
farklı sunuculara dağıtılacaktır. Olası dağıtım şemaları nelerdir?
- Dikey dağıtım(dikey bölümleme) - en basit durumda
bireysel veritabanı tablolarının başka bir sunucuya aktarılmasıdır. saat
bunun için farklı sunuculara erişmek için komut dosyalarını değiştirmemiz gerekiyor
farklı veriler. Limitte, her tabloyu ayrı bir sunucuda saklayabiliriz.
(pratikte bunun faydalı olması pek olası olmasa da). Açıkçası, böyle
dağıtım, verileri birleştiren SQL sorguları yapma yeteneğimizi kaybederiz.
farklı sunucularda bulunan iki tablo. Gerekirse uygulayabilirsiniz
uygulamada mantığı birleştir, ancak DBMS'deki kadar verimli olmayacak.
Bu nedenle, bir veritabanını bölerken, tablolar arasındaki ilişkileri analiz etmeniz gerekir,
en bağımsız tabloları yerleştirmek için.Daha karmaşık durum
tabanın dikey dağılımı, bir tablonun parçalanmasıdır.
sütunları bir sunucuda ve bazıları başka bir sunucuda. Böyle bir teknik
daha az yaygındır, ancak örneğin küçükleri ayırmak için kullanılabilir
ve nadiren erişilen büyük miktardaki verilerden sık sık güncellenen veriler. - yatay dağılım(yatay bölümleme) - şunlardan oluşur
birden çok sunucu arasında bir tablodan veri dağıtma. Aslında, üzerinde
her sunucu aynı yapıda bir tablo oluşturur ve
belirli bir veri parçası. Verileri sunucular arasında farklı şekillerde dağıtabilirsiniz.
ölçüt: aralığa göre (kimliği olan kayıtlar< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, geri kalanı - sunucuya B) veya bazı alanlardan karma işlevinin değerine göre
kayıtlar. Verilerin yatay olarak bölümlenmesi, sınırsız depolamanıza izin verir
Ancak kayıt sayısı seçimi zorlaştırmaktadır. En verimli seçim
yalnızca hangi sunucuda saklandıkları bilindiğinde kaydeder.
Doğru veri dağıtım şemasını seçmek için,
veritabanının yapısını dikkatlice analiz edin. Mevcut tablolar (ve muhtemelen
bireysel alanlar) kayıtlara erişim sıklığına göre, frekansa göre sınıflandırılabilir
güncellemeler ve ilişkilere göre (birkaç
tablolar).
Yukarıda belirtildiği gibi, veritabanına ek olarak, site genellikle
ikili dosyalar için depo. Dağıtılmış dosya depolama sistemleri
(aslında dosya sistemleri) iki sınıfa ayrılabilir.
- Çalışma işletim sistemi düzeyinde. Aynı zamanda, için
uygulamalar, böyle bir sistemdeki dosyalarla çalışmak, normal çalışmadan farklı değildir.
Dosyalar. Sunucular arasındaki bilgi alışverişi işletim sistemi tarafından gerçekleştirilir.
Bu tür dosya sistemlerinin örnekleri arasında iyi bilinenler yer alır.
NFS ailesi veya daha az bilinen ancak daha modern Lustre sistemi. - uygulandı uygulama düzeyinde dağıtılmış
depolar, bilgi alışverişi işinin
Ek. Genellikle kolaylık sağlamak için, depolama ile çalışma işlevleri
ayrı kitaplık. Bu tür depolamanın en parlak örneklerinden biri, tarafından geliştirilen MogileFS'dir.
LiveJournal'ın yaratıcıları. Başka bir yaygın örnek, kullanımdır.
WebDAV protokolü ve destekleyici depolaması.
Unutulmamalıdır ki, veri dağılımı sadece karar vermemektedir.
bir depolama sorunu, aynı zamanda kısmen bir yük dağıtım sorunu - her birinde
sunucuda daha az kayıt vardır ve bu nedenle daha hızlı işlenirler.
Hesaplama ve veri dağıtım yöntemlerinin birleşimi,
ile çalışabilen potansiyel olarak sınırsız ölçeklenebilir mimari
herhangi bir miktarda veri ve herhangi bir yük.
sonuçlar
Söylenenleri özetleyerek, sonuçları kısa tezler şeklinde formüle ediyoruz.
- İki ana (ve ilgili) ölçeklendirme zorluğu, hesaplama dağıtımı ve veri dağıtımıdır.
- Tipik bir site mimarisi, rollerin ve
ön uç, arka uç, veritabanı ve bazen dosya depolamayı içerir - Az miktarda veri ve büyük yükler için,
veritabanı yansıtma - zaman uyumlu veya zaman uyumsuz çoğaltma - Büyük miktarda veriyle, veritabanını dağıtmak gerekir - bölünmüş
dikey veya yatay - İkili dosyalar dağıtılmış dosya sistemlerinde saklanır
(işletim sistemi düzeyinde veya uygulamada uygulanır) - Dengeleme (taleplerin dağılımı) tek tip veya
işlevselliğe göre bölme ile; bir dengeleme düğümü ile veya istemci tarafında - Doğru yöntem kombinasyonu, herhangi bir yükü tutmanıza izin verecektir;)
Bağlantılar
Bu konuyu ilginç İngilizce sitelerde ve bloglarda incelemeye devam edebilirsiniz.
Oleg Spiryaev
Son zamanlarda, orta sınıf ve üst düzey sunucuların, raflarda veya kümelerde birleştirilmiş giriş düzeyi sunucu grupları tarafından aktif olarak değiştirildiğini iddia etmek alışılmadık bir durum değil. Ancak, bazı uzmanlar aynı fikirde değil. Böylece Dataquest'e göre 2000-2002 yılları arasında 500 bin dolar ve üzeri fiyatlı modellerin (orta ve eski SMP sunucuları dahil) toplam sunucu satışları içindeki payı %38'den %52'ye yükseldi.
IDC'den alınan diğer veriler, düşük kaliteli çift işlemcili sunucu sektöründe büyümeyi (en azından makine sayısı açısından) göstermektedir. IDC ayrıca 2005 yılında 50.000 ila 3 milyon dolarlık sunucu için en yaygın işletim sisteminin Unix olacağını tahmin ediyor. Bu verilerin karşılaştırılması, orta ve üst düzey Unix sunucularının baskın veri merkezi platformu olmaya devam edeceğini, ancak artan sayıda daha küçük (genellikle 2 soketli) sunucularla destekleneceğini gösteriyor.
Bu eğilim, veri merkezlerindeki farklı bilgi işlem düzeylerinin ayrılmasının bir sonucu olarak ortaya çıkmıştır (Şekil 1). Katman 1 veya ön katman, kademeli olarak küçük sunuculardan oluşan bir ölçeklendirme modeline geçiş yaparken, katman 3'e (veritabanı katmanı) ölçek büyütme sunucuları hakimdir. Katman 2 (uygulama katmanı), dikey ve yatay mimarilerin bir arada bulunduğu alan olur.
Dikey ve yatay mimariler
Dikey ve yatay mimariler arasındaki temel farkları düşünün. Ölçek büyütme sunucuları, dörtten fazla CPU'ya sahip büyük SMP (simetrik çok işlemli veya paylaşılan bellek) sistemleridir. Tüm işlemcilerin, belleğin ve G / Ç bileşenlerinin çalışmasını yöneten işletim sisteminin yalnızca bir kopyasını kullanırlar. Tipik olarak, bu kaynakların tümü tek bir rafta veya kabinde barındırılır. Bu sunuculara olan ara bağlantılar, düşük gecikme süresi ve tutarlı önbellek erişimi ile yüksek hızlı bir merkezi veya arka panel üzerinden yapılır. Kabinin içine ek anakartlar takarak kaynak ekleyebilirsiniz. Dikey mimari sistemlerde (veya SMP sistemlerinde) bellek paylaşılır, yani tüm işlemciler ve G/Ç bileşenlerinin tüm belleğe erişimi vardır. Kullanıcı, belleği tek bir büyük nesne olarak "görür".
Alternatif bir yatay ölçeklendirmede, sistemler bir ağ üzerinden bağlanır veya birlikte kümelenir. Ara bağlantılar tipik olarak, dikey sistemlere kıyasla daha düşük verim ve daha yüksek gecikme süresi sağlayan Hızlı Ethernet, Gigabit Ethernet (GBE) ve Ölçeklenebilir Tutarlı Ara Bağlantı (SCI) gibi standart ağ teknolojilerini kullanır. Bu durumda kaynaklar, genellikle bir ila dört işlemci içeren düğümler arasında dağıtılır; her düğümün kendi işlemcisi ve belleği vardır ve kendi G/Ç alt sistemine sahip olabilir veya bunu diğer düğümlerle paylaşabilir. Her düğüm, işletim sisteminin ayrı bir kopyasını çalıştırır. Kaynaklar, bir düğüme kaynak eklenerek değil, düğümler eklenerek genişletilir. Yatay sistemlerde bellek dağıtılır, yani her düğümün işlemcileri ve G / Ç alt sistemi tarafından doğrudan erişilen kendi belleği vardır. Bu kaynaklara başka bir düğümden erişim, bulundukları düğümden çok daha yavaştır. Ayrıca, yatay bir mimaride, belleğe tutarlı bir düğüm erişimi yoktur ve kullanılan uygulamalar nispeten az kaynak tüketir, bu nedenle bir düğüme "uyarlar" ve tutarlı erişime ihtiyaç duymazlar. Bir uygulamanın birden çok düğüme ihtiyacı varsa, kendi başına tutarlı bellek erişimi sağlamalıdır.
Yatay bir sistem, uygulamaların gereksinimlerini karşılıyorsa, elde edilmesi daha ucuz olduğu için bu mimari tercih edilir. Tipik olarak, yatay sistemler için işlemci başına edinme maliyeti, dikey sistemlere göre daha düşüktür. Fiyat farkı, dikey sistemlerin daha güçlü güvenilirlik, kullanılabilirlik ve servis verilebilirlik - RAS (güvenilirlik, kullanılabilirlik, servis verilebilirlik) işlevlerini ve ayrıca yüksek performanslı ara bağlantıları kullanması gerçeğiyle açıklanmaktadır. Ancak, yatay mimariye sahip sistemlerin kullanımında bir takım kısıtlamalar vardır. Aşağıda yatay sistemlerin hangi koşullarda kullanılabileceğini ve dikey ölçeklendirmenin ne zaman gerekli olduğunu tartışacağız.
Tek bir büyük SMP sunucusuna ek olarak, dikey bir mimari, tek bir büyük ölçekli uygulama için kullanılan büyük SMP sunucularının kümelerini de içerir.
Son zamanlarda piyasaya sunulan modüler veya blade sunucular, genellikle bir veya iki işlemci ile donatılmış yatay sunuculara örnektir. Burada küme, her biri 1 ila 4 CPU'nun kurulu olduğu bir giriş seviyesi SMP sunucusuna sahip olan küçük düğümlerden oluşur.
Ölçeklendirmenin başka bir yolu, her biri kendi işletim sistemi kopyasına veya işletim sistemi mikro çekirdeğinin bir kopyasına sahip olan, tek bir kabine kurulu birçok küçük işlemciden oluşan büyük kitlesel paralel bilgi işlem (MPP) sistemleridir. Şu anda, çoğunlukla özel çözümleri temsil eden yalnızca birkaç MPP sistemi üretilmektedir. Bunlar örneğin NCR tarafından üretilen Terradata sistemleri, IBM RS/6000SP (SP-2) ve HP Tandem durmaksızın.
Tablo 1. Dikey ve yatay mimarilerin özellikleri
| Parametre | Dikey sistemler | Yatay sistemler |
| Hafıza | Büyük Paylaşılan | Küçük adanmış |
| Canlı Yayınlar | Birbirine bağlı birçok iş parçacığı | Çok sayıda bağımsız konu |
| ara bağlantılar | Güçlü bağlantılı dahili | Gevşek bağlı dış |
| RAS | Güçlü tek sistemli RAS | Çoğaltma kullanan güçlü RAS |
| CPU'lar | Çok sayıda standart | Çok sayıda standart |
| işletim sistemi | Birden çok CPU için bir işletim sistemi kopyası | Birden çok işletim sistemi kopyası (1-4 işlemci başına bir kopya) |
| Düzen | bir dolapta | Bir rafa çok sayıda sunucu yerleştirme |
| Yerleşim yoğunluğu | Birim taban alanı başına yüksek işlemci yoğunluğu | |
| Teçhizat | Standart ve özel tasarım | Standart |
| ölçekleme | Tek bir sunucu kasası içinde | Çoklu sunucu ölçeği |
| Eklenti | Sunucuya ek bileşenler yükleyerek | Yeni düğümler ekleyerek |
| Mimari | 64 bit | 32 ve 64 bit |
Sekme. 1 dikey ve yatay mimarilerin karşılaştırmalı analizine izin verir.
- Dikey sistemlerde bellek paylaşılır ve önbellek erişimi tutarlıdır.
- Dikey sistemler, birbirleriyle iletişim kurması gereken görev dizileri için idealdir.
- Dikey sistemler, güçlü RAS işlevleri ile karakterize edilir ve yatay sistemlerde, büyük çoğaltma kullanılarak kullanılabilirlik gerçekleştirilir (bir kümede birkaç düğüm birbirine bağlanır, bu nedenle bunlardan birinin arızalanması tüm sistemin çalışması üzerinde çok az etkiye sahiptir).
- Dikey sistemlerde, işletim sisteminin bir kopyası tüm kaynakları kapsar. Orta çerçeveler ve üst düzey Sun Microsystems sunucuları (Sun Fire 4800 - Sun Fire 15K) gibi bazı dikey sistemler, daha küçük dikey sunuculara bölünebilir.
- Dikey sistemler mümkün olduğunca çok sayıda standart bileşen kullanır, ancak bazı ana bileşenler (ara bağlantılar gibi) özel olarak tasarlanmıştır.
- Tower sistemler, mevcut bir çerçeveye ek bileşenler (daha güçlü işlemciler, daha fazla bellek, daha güçlü G/Ç bağlantıları vb.) takılarak genişletilebilir. Yatay sistemler, bir düğüm ekleyerek veya eski düğümleri yenileriyle değiştirerek genişler.
- Hemen hemen tüm dikey sistemler 64-bit iken yatay sistemler 32-bit veya 64-bit olabilir.
Bazı uygulama türleri için dikey sistemler daha uygundur, diğerleri ise yatay olanlar için daha uygundur, ancak çoğu durumda en uygun mimari seçimi görevin boyutuna bağlıdır. Masada. 2, dikey veya yatay mimarinin optimal olduğu uygulama örneklerini gösterir.
Tablo 2. Dikey ve yatay mimariler için uygulama türleri
Durum bilgisi olmayan, küçük ölçekli ve kolayca çoğaltılabilen uygulamalar, küçük ve modüler sunucular için çok uygundur. Ve sistem içinde yoğun veri aktarımı gerektiren durum bilgisi ve büyük miktarda veri kullanan uygulamalar için dikey sunucular idealdir. Yüksek Performanslı Teknik Hesaplama (HPTC) pazarında, iş parçacıklarının birbirine bağlı olduğu ve birbirleriyle iletişim kurduğu birçok uygulama vardır. Büyük miktarda paylaşılan bellek gerektiren uygulamalar da vardır. Bu iki tür uygulama için büyük SMP sunucuları en uygunudur. Ancak, yürütme iş parçacıklarının bağımsız olduğu ve büyük miktarda paylaşılan bellek gerektirmediği HPTC uygulamaları da vardır. Bu uygulamalar bölümlenebilir ve bu nedenle küçük sunucu kümeleri bunları çalıştırmak için idealdir. Benzer şekilde, bazı ticari uygulamalar bölümlemeyi destekler ve yatay sunucular onlar için idealdir, diğerleri bölümlenemez, dolayısıyla dikey sunucular onlar için en iyi platformdur.
Performansı Etkileyen Faktörler
Tüm büyük veri merkezleri paralel bilgisayarlardır. Burada kümeler bile paralel sistemlerin özel bir türü olarak düşünülebilir. Yüksek performans, güçlü işlemcilere, yüksek hızlı ara bağlantılara ve G/Ç'ye, ölçeklenebilir bir işletim sistemine, optimize edilmiş uygulamalara ve gelişmiş RAS özelliklerine sahip dengeli bir sistem gerektirir.
İşlemciler ve sistem ara bağlantıları
İşlemciler kesinlikle önemli bir bileşendir, ancak sistemin genel performansını yalnızca kısmen belirlerler. İşlemcilerin maksimum yükte çalışmasını sağlamak daha önemlidir. Yalnızca %50 yüklü olan güçlü bir işlemci, yalnızca %80 yüklü olan daha yavaş bir işlemciden daha kötü performans gösterecektir.
Ayrıca paralel bir sistemdeki işlemci sayısı arttıkça ön plana çıkan onların gücü değil, sistem ara bağlantılarıdır. Verileri diskten, bellekten ve ağdan işlemciye taşımaktan sorumludurlar. Bir kümede ara bağlantı, Fast Ethernet veya Gigabit Ethernet gibi bir ağ bağlantısıdır. Küme ara bağlantıları, verileri düğümler arasında taşırken, sistem ara bağlantıları, verileri tek bir sistem içinde taşır. Ara bağlantı çok yavaşsa, işlemci boşta veri bekler.
Sistem ara bağlantıları, tutarlı önbellek erişimi sağlamak için gerekli olan veri adreslerini taşımak için de kullanılır. Sistem ara bağlantısı, veri adreslerini çok yavaş aktarırsa, işlemci, bunlara erişmek için adreslerini bilmesi gerektiğinden, verileri beklerken tekrar boşta olacaktır. Hızlı ara bağlantılar, yüksek verim ve düşük gecikme süresi sağlar (veri talebinden veri aktarımının başlamasına kadar kısa süre).
Yatay ve dikey sistemler arasındaki temel teknik fark, ara bağlantılarının bant genişliği ve gecikmesidir. Küme ara bağlantıları, Hızlı Ethernet için 125 MB/sn ile SCI için 200 MB/sn arasında değişen verime ve GBE için 100 kns'den SCI için 10 kns'ye kadar gecikme süresine sahip olabilir. InfiniBand arabirimini kullanarak, ilk sürüm için yaklaşık 250 MB/sn ve sonraki sürümler için 3 GB/sn'ye kadar olan en yüksek hızlarla daha hızlı ara bağlantılar gerçekleştirmek mümkündür.
Giriş ve çıkış
Ara bağlantının diskten ve ağdan hızlı bir şekilde veri alabilmesi ve işlemcilere aktarabilmesi için hızlı I/O gereklidir. G/Ç alt sistemindeki bir darboğaz, en hızlı ara bağlantıları ve işlemcileri bile olumsuz etkileyebilir.
İşletim sistemi
İşletim sistemi yeterince ölçeklenebilir değilse, en iyi donanım bile verimsizdir. Yatay sistemler için, işletim sistemi ölçeklenebilirliği o kadar önemli değildir, çünkü tek bir düğümde veya işletim sisteminin tek bir kopyasıyla dörtten fazla işlemci çalışmaz.
Sistem kullanılabilirliği
Genel olarak konuşursak, bir sistemin kullanılabilirliği büyük ölçüde mimarinin türüne bağlıdır. Büyük SMP sistemlerinde, RAS işlevselliği sistemde yerleşiktir ve iki ila dört düğüm için yük devretme ile artırılır. Yatay RAS sistemlerinde, tek tek düğümler daha kötüdür, ancak bu işlevlerin iyileştirilmesi, düğümlerin çoklu kopyalanmasıyla sağlanır.
Optimize Edilmiş Uygulamalar
Uygulamaların bilgisayar sistem mimarisi için optimize edilmesi gerekir. SMP sistemleri için uygulama yazmanın ve optimize etmenin en kolay yolu. Başlıca ticari uygulamalar, özellikle SMP sistemleri için optimize edilmiştir ve hatta bunlar üzerinde geliştirilmiştir, bu nedenle SMP, son on yılda orta ve üst düzey sistemler pazarına hakim olmuştur.
Uygulama boyutu
Daha önce belirtildiği gibi, büyük SMP sistemleri, yeterli sistem performansı sağlamak için yüksek hızlı ara bağlantılar kullanır. Yatay sistemler, düğümler arasında sık sık veri aktarmaya ihtiyaç duyulduğunda, düşük aktarım hızı ve önemli ara bağlantı gecikmesi nedeniyle performans sorunları yaşayabilir. Bununla birlikte, bazı uygulamaların yüksek performans elde etmek için yüksek ara bağlantı hızlarına ihtiyacı yoktur - genellikle küçük uygulamalar ve kolayca çoğaltılabilen uygulamalar (örneğin, Web sunucuları, proxy sunucuları, güvenlik duvarları ve küçük uygulama sunucuları). Bu tür yatay sistemlerde, her düğüm diğerlerinin çalışmasından bağımsız olarak küçük bir görevi yerine getirir.
Örneğin, bir yatay (veya dağıtılmış bellek) mimarisi durumunda, dört işlemci düğümü (her biri ayrı RAM'e ve ayrılmış veya paylaşılan bir G/Ç alt sistemine sahip) Gigabit Ethernet gibi bir ağ ara bağlantısını kullanabilir. Bu bilgi işlem ortamı, üç tür iş yükü çalıştırır. En küçük yük bir düğüme sığar, ancak arttıkça tamamlanması birkaç düğüm alır. Uzmanlara göre, aynı görevi birden fazla düğümde gerçekleştirirken, yavaş düğümler arası ara bağlantılar nedeniyle performans önemli ölçüde düşer. Birbiriyle iletişim kurması gerekmeyen küçük iş yükleri yatay bir mimariyle iyi çalışır, ancak içinde büyük ölçekli iş yükleri çalıştırmak sorun yaratır.
Büyük bir SMP sistem yapılandırması, örneğin 100'e kadar işlemci, 576 GB paylaşılan bellek ve yüksek hızlı ara bağlantılar içerebilir. Böyle bir sistem, düğümler arasında iletişim olmadığı ve süreçler arasında verimli iletişim olmadığı için her tür iş yükünü işleyebilir. Tüm CPU'lar tüm disklere, tüm belleğe ve ağ bağlantılarına aynı anda erişebilir - bu, SMP sistemlerinin (veya dikey sistemlerin) önemli bir özelliğidir.
Soru genellikle büyük SMP'lere küçük yüklerin yerleştirilmesinin tavsiye edilebilirliği ile ilgili olarak ortaya çıkar. Ekonomik açıdan teknik olarak mümkün olsa da, bu yaklaşım kendisini haklı çıkarmaz. Büyük SMP'ler için, işlemci başına edinme maliyeti, daha küçük sistemlere göre daha yüksektir. Bu nedenle, uygulama küçük bir ana bilgisayarda (veya birden çok küçük ana bilgisayarda) çalışabiliyorsa ve büyük yönetim sorunları oluşturmuyorsa, ölçek genişletme dağıtım için daha uygundur. Ancak uygulama küçük bir ana bilgisayarda (veya birden çok ana bilgisayarda) çalıştırılamayacak kadar büyükse, hem performans hem de sistem yönetimi için büyük bir SMP sunucusu en iyi seçenektir.
Veritabanı düzeyinde performans
Buradaki ana soru, tek orta ve büyük SMP sunucularının performansını bir küçük sunucu kümesiyle (dört işlemciden fazla olmayan) karşılaştırmaktır.
Ölçeklenebilirliği tartışırken, üreticiler bir dizi teknik terim kullanır. Dolayısıyla, SMP için performans artışı (Hızlanma), birkaç işlemcide ve bir işlemcide uygulama yürütme hızlarının oranı olarak tanımlanır. Doğrusal hızlanma, örneğin, 40 işlemcide uygulamanın bir tek işlemciden 40 kat (40 kat) daha hızlı çalıştığı anlamına gelir. Performans artışı işlemci sayısından bağımsızdır, yani 24 işlemcili bir konfigürasyon için 48 işlemcili ile aynı olacaktır. Küme hızlandırma, işlemciler değil, yalnızca düğüm sayısı kullanılarak hesaplanması bakımından farklılık gösterir. SMP performans kazanımları gibi, küme performans kazanımları da değişen sayıda düğüm için sabit kalır.
Ölçekleme verimliliği, uygulamaların, özellikle küme uygulamalarının çok sayıda düğüme ölçekleme yeteneğini karakterize eder. Genellikle ölçekleme verimliliğinin, ölçüme katılan düğümlerin sayısına bağlı olduğuna inanılmaktadır. SMP ölçekleme verimliliği, işlemci sayısına bölünen performans kazancıdır ve küme verimliliği, kümenin içindeki düğüm sayısına bölünen performans kazancıdır. İki düğümde %90 ölçek verimliliği dört düğümde %90 ölçek verimliliği ile aynı olmadığından, yanlış resmi almamak için bu ayarların ne anlama geldiğini anlamanız gerekir.
Şek. Şekil 2 üç grafiği göstermektedir: ideal doğrusal ölçeklenebilirlik, 24 soketli bir SMP sunucusu için %95 ölçeklenebilirlik ve iki adet 4 soketli sunucudan oluşan bir küme için %90 ölçeklenebilirlik. Veritabanlarının kümelerde (yatay ölçekleme ile) ölçeklenebilirliği konusunda belirli sınırlamalar olduğu görülebilir. Birçok küçük sunucuyu birbirine bağlamak, orta ila büyük uygulamalar için gereken ölçeklenebilirliği sağlamaz. Bunun nedeni, küme içi ara bağlantı bant genişliği sınırlamaları, küme yönetimiyle ilişkili veritabanı yazılımı üzerindeki ek yük ve dağıtılmış bellek kümesi ortamları için uygulama yazmanın zorluğudur.
Yayınlanan kıyaslama sonuçları, örneğin, Oracle9i RAC'nin (Gerçek Uygulama Kümesi) 1.8'lik bir performans artışına ve %90'lık bir ölçekleme verimliliğine sahip olduğunu göstermektedir. Bu ölçeklenebilirlik verimliliği yeterince yüksek görünebilir, ancak aslında dört düğüm için %90 ölçeklenebilirlik, büyük SMP sunucularının sonuçlarıyla karşılaştırıldığında verimsizdir.
Uygulama düzeyinde performans
Üç katmanlı bir veri merkezindeki uygulama katmanı, veritabanı katmanından çok farklıdır. Tipik olarak, bu düzeydeki uygulamalar durumsuzdur - başka bir deyişle, sunucunun kendisinde hiçbir veri depolanmaz veya yalnızca küçük bir kısmı depolanır. Bu katman, uygulama hizmetleri için iş kurallarını içerir. İşlemler uygulama katmanına gelir ve onun tarafından işlenir. Verilerin yazılması veya okunması gerektiğinde, işlemler veritabanı katmanına iletilir. Uygulama sunucuları, çok sayıda bağlantı performansı olumsuz etkilediği için veritabanı bağlantılarını birleştirme eğilimindedir.
Çoğu durumda, uygulama sunucusu katmanı, tek bir uygulama hizmeti için veritabanı katmanından çok daha fazla işlemci gerektirir. Örneğin, SAP R/3 durumunda, bu oran her veritabanı işlemcisi için yaklaşık 10 işlemcidir, yani SAP R/3, veritabanı katmanı için 20 işlemci gerektiriyorsa, uygulama katmanı için yaklaşık 200 işlemci olmalıdır. Soru, dağıtmanın daha karlı olduğu - 100 iki işlemcili sunucu veya on 20 işlemcili sunucu. Benzer şekilde Oracle'da uygulama işlemcilerinin veritabanı işlemcilerine oranı yaklaşık 5'e 1'dir.
Uygulama sunucularının birkaç düğüm üzerinde dağıtılmasına gerek olmadığı düşünülmektedir. Uygulama yazılımının birden çok kopyası, farklı kapasitedeki farklı fiziksel sunuculara veya büyük sunucuların dinamik etki alanlarına dağıtılabilir.
Uygulama katmanı için gereken işlemci sayısı, bilgisayar mimarisinden bağımsız olarak yaklaşık olarak aynı olacaktır. Yatay bir mimari için donanım ve yazılım maliyetleri, işlemci başına maliyet daha düşük olduğu için daha düşük olacaktır. Çoğu durumda, yatay sistemler SLA'yı karşılamak için gereken performansı sağlayabilir. Yazılım lisanslarının alınmasıyla ilgili maliyetler, her iki mimari için de yaklaşık olarak aynıdır.
Aynı zamanda, yatay bir mimari için altyapı yönetimi ve bakım maliyetleri daha yüksek olabilir. Yatay sistemlere dağıtıldığında, işletim sisteminin ve uygulama sunucusu yazılımının birden çok kopyası kullanılır. Öte yandan, altyapıyı sürdürmenin maliyetleri genellikle işletim sisteminin ve uygulamaların kopya sayısıyla orantılı olarak artar. Ayrıca, yatay bir mimari için yedekleme ve olağanüstü durum kurtarma, merkezi olmayan hale gelir ve ağ altyapısını yönetmek daha zordur.
Sistem yönetiminin maliyetini ölçmek zordur. Genellikle, uygulama sunucularının yatay ve dikey dağıtımını karşılaştırmaya yönelik modeller, daha az sayıda, daha güçlü sunucuları (dikey sunucular) yönetmenin birçok küçük sunucuyu yönetmekten daha ucuz olduğunu gösterir. Genel olarak, uygulama katmanını dağıtmak için mimari türünü seçerken, BT yöneticileri donanım edinme maliyetini ayrıntılı olarak analiz etmelidir.
Mimarinin Erişilebilirlik Üzerindeki Etkisi
Kullanılabilirlik günümüzün veri merkezleri için kritik öneme sahiptir - uygulama hizmetleri 7 gün 24 saat (günde 24 saat, haftada 7 gün, yılda 365 gün) erişilebilir olmalıdır. Belirli bir veri merkezinin ihtiyaçlarına bağlı olarak, farklı yüksek kullanılabilirlik şemaları kullanılır. Belirli bir çözüm seçmek için izin verilen arıza süresini (planlı ve plansız) belirlemek gerekir. Şek. Şekil 3, kullanılabilirlik yüzdesinin kesinti süresini nasıl etkilediğini gösterir.
Kullanılabilirlik gereksinimleri arttıkça çözümün maliyeti de artar. Veri merkezi yöneticileri, hangi maliyet, karmaşıklık ve kullanılabilirlik kombinasyonunun hizmet düzeyi gereksinimlerini en iyi şekilde karşıladığını belirlemelidir. Yaklaşık %99,95 kullanılabilirlik gerektiren veri merkezleri, tam donanım yedekliliği ve çevrimiçi bakım gibi RAS özelliklerine sahip tek bir SMP sunucusunu dağıtabilir.
Ancak, %99,95'in üzerinde kullanılabilirlik elde etmek için bir küme gereklidir. HA (Yüksek Kullanılabilirlik) yük devretme özelliğine sahip Sun Cluster yazılımı, %99,975 kullanılabilirlik sağlar. Yük Devretme HA, birincil ve etkin bekleme sunucusunu kullanır; Birincil sunucu başarısız olursa, yedekleme, yükü devralır. Hizmetin yeniden başlatma süresi uygulamaya bağlıdır ve özellikle işlemleri kurtarmak için büyük veri yoğun geri alma gerektiren veritabanı uygulamaları için birkaç dakika sürebilir.
Veri merkezi için birkaç dakikalık kesinti kabul edilemezse, uygulamanın iki veya daha fazla düğüme dağıtıldığı aktif-aktif bir sistem bir çözüm olabilir: bunlardan biri başarısız olursa, geri kalanı uygulamayı çalıştırmaya devam eder. . Sonuç olarak, kesinti çok kısa olacaktır (bazı müşteriler 1 dakikadan az sürdüğünü bildirmektedir), bazen kullanıcı düğümün arızasını fark etmeyebilir.
Dikey sunucular, planlı ve plansız kapalı kalma süresini en aza indirmek için birçok RAS özelliğini tek bir sunucuya yerleştirerek yüksek kullanılabilirlik sağlar. Yatay sunucularda, yüksek düzeyde RAS sağlayan özellikler, tek bir sunucu düzeyinde değil, birkaç sunucunun çoğaltılması ve yerleştirilmesi yoluyla uygulanır. RAS işlevselliğinin ve ara bağlantıların farklı uygulamaları nedeniyle, yatay sunucular genellikle işlemci başına daha ucuzdur.
Üç katmanlı bir mimari için, Web sunucularının dağıtımı, yatay yüksek kullanılabilirliğe iyi bir örnektir. Her biri Web sunucusu yazılımının ayrı bir kopyasına sahip olan birçok küçük sunucuyu dağıtabilirsiniz. Bir Web sunucusu başarısız olursa, işlemleri kalan sağlıklı sunucular arasında yeniden dağıtılır. Uygulama sunucuları söz konusu olduğunda, hem yatay hem de dikey sunucularda barındırılabilirler ve yedeklilik yoluyla yüksek kullanılabilirlik sağlanır. İster birkaç büyük SMP sunucusunu ister daha küçük sunucuları dağıtın, uygulama katmanında yüksek RAS elde etmenin birincil yolu çoğaltma olmaya devam ediyor.
Ancak veritabanı katmanı için durum farklıdır. Veritabanları durum bilgisidir ve doğası gereği, çoğu durumda verilerin bölümlenmesini ve tüm işlemcilerden/düğümlerden erişilebilir olmasını gerektirir. Bu, yedekli yüksek kullanılabilirlik için Sun Cluster veya Oracle9i RAC (çok yüksek kullanılabilirlik için) gibi kümeleme yazılımlarını kullanmanız gerektiği anlamına gelir.
sonuçlar
Hem dikey hem de yatay mimariler, günümüzün veri merkezinde kendi nişlerine sahiptir. Bugün odak noktası modüler sunucular ve paralel veritabanları gibi gelişmekte olan teknolojiler olsa da, pazar orta ve üst düzey sunuculara yönelik güçlü talep görmeye devam ediyor.
Dikey ve yatay sistemler aynı yazılımı, işletim sistemini ve hatta aynı işlemcileri kullanabilir. Fiyat ve performansı etkileyen temel fark, her iki mimaride de kullanılan ara bağlantılardır. Yatay sunucular gevşek bağlı harici ara bağlantılar kullanırken dikey sunucular daha hızlı veri aktarım hızları için sıkı bağlantılı ara bağlantılar kullanır.
Ön uç için yatay sunucular genellikle performans, toplam sahip olma maliyeti ve kullanılabilirlik açısından en iyi çözümü sağlar. Uygulama katmanı için hem dikey hem de yatay mimariler etkin bir şekilde kullanılabilir. Veritabanı katmanı için, gereken kullanılabilirlik düzeyi ne olursa olsun dikey sunucular en iyi çözümdür.
Yani bir web sitesi yaptınız. Ziyaretçinin her gün daha iyi sonuçlar vererek yavaş ama emin adımlarla nasıl karşı çıktığını izlemek her zaman ilginç ve heyecan vericidir. Ancak bir gün, hiç beklemediğiniz bir anda, birisi Reddit veya Hacker Haberlerinde (veya Habré'de - yaklaşık olarak kişi başına) kaynağınıza bir bağlantı gönderecek ve sunucunuz çökecek.
Yeni düzenli kullanıcılar almak yerine boş bir sayfa ile kalacaksınız. Bu noktada, sunucuyu hizmete hazır hale getirmenize hiçbir şey yardımcı olmaz ve trafik sonsuza kadar kaybolur. Bu tür sorunlardan nasıl kaçınılır? Bu yazıda, hakkında konuşacağız optimizasyon ve ölçeklendirme.
Optimizasyon hakkında biraz
Herkes temel tavsiyeyi bilir: PHP'nin en son sürümüne güncelleme (5.5 şimdi yerleşik OpCache'ye sahiptir), veritabanındaki dizinleri sıralayın, önbellek statik ("Hakkımızda", "SSS" vb. gibi nadiren değişen sayfalar. ).
Ayrıca, belirli bir optimizasyon özelliğinden bahsetmeye değer - örneğin Nginx gibi Apache olmayan bir sunucu tarafından statik içerik sunmak. ve ağır Apache'nin sunucu işlemesi gerektiren dosyaları göndermesine izin verin. denir ters proxy.
ölçekleme
İki tür ölçeklendirme vardır - dikey ve yatay.
Anladığım kadarıyla, bir site yazılımı değiştirmeden trafiği kaldırabiliyorsa ölçeklenebilir.
Dikey ölçekleme.
Bir web uygulaması sunan bir sunucu düşünün. 4 GB RAM, i5 işlemci ve 1 TB HDD'ye sahiptir. İşini iyi yapıyor, ancak daha yüksek trafiği daha iyi idare etmek için RAM'inizi 16 GB'a yükseltmeye, bir i7 işlemciye yükseltmeye ve bir SSD sürücüsü için ayrılmaya karar veriyorsunuz. Artık sunucu çok daha güçlü ve yüksek yükleri kaldırabiliyor. Bu dikey ölçeklendirmedir.
Yatay ölçekleme.
Yatay ölçeklendirme, birlikte siteye hizmet eden birbirine bağlı (genellikle çok güçlü olmayan) sunuculardan oluşan bir kümenin oluşturulmasıdır. Bu durumda kullanılır yük dengeleyici(diğer adıyla yük dengeleyici) ana işlevi hangi sunucuya istek gönderileceğini belirlemek olan bir makine veya programdır. Kümedeki sunucular, birbirleri hakkında hiçbir şey bilmeden uygulama hizmetini paylaşır, böylece sitenizin verimini ve hata toleransını büyük ölçüde artırır.
İki tür dengeleyici vardır - donanım ve yazılım. Yazılım - normal bir sunucuya kurulur ve tüm trafiği alarak uygun işleyicilere iletir. Böyle bir dengeleyici, örneğin Nginx olabilir. “Optimizasyon” bölümünde, tüm statik dosya isteklerini durdurdu ve bu istekleri Apache'ye yük olmadan kendisi yaptı. Bir diğer popüler yük dengeleme yazılımı Squid'dir. Şahsen ben her zaman kullanırım çünkü. Dengelemenin en derin yönlerini kontrol etmek için harika bir kullanıcı dostu arayüz sağlar.
Donanım dengeleyici, tek amacı yükü dağıtmak olan özel bir makinedir. Genellikle bu makinede, artık üretici tarafından geliştirilen yazılım dışında hiçbir yazılım yüklenmez. Donanım yük dengeleyicileri hakkında bilgi edinebilirsiniz.
Bu iki yöntemin birbirini dışlamadığını unutmayın. Herhangi bir makineyi dikey olarak ölçekleyebilirsiniz (aka nodu) sisteminizde.
Bu yazıda yatay ölçeklemeyi tartışıyoruz. uygulanması daha zor olmasına rağmen daha ucuz ve daha verimlidir.
Kalıcı bağlantı
PHP uygulamalarını ölçeklerken, birkaç zor problem vardır. Bunlardan biri kullanıcı oturum verileriyle çalışıyor. Sonuçta, sitede oturum açtıysanız ve dengeleyici bir sonraki isteğinizi başka bir makineye gönderirse, yeni makine zaten oturum açtığınızı bilmeyecek. Bu durumda, kalıcı bir bağlantı kullanabilirsiniz. Bu, dengeleyicinin kullanıcının isteğini en son hangi düğümden gönderdiğini hatırladığı ve bir sonraki isteği oraya gönderdiği anlamına gelir. Bununla birlikte, dengeleyicinin yüz binlerce isteği işlemeye ek olarak, işlevlerle aşırı yüklendiği ortaya çıktı, ayrıca bunları tam olarak nasıl işlediğini hatırlaması gerekiyor, bunun sonucunda dengeleyicinin kendisi sistemde bir darboğaz haline geliyor.
Yerel veri alışverişi.
Kullanıcı oturumu verilerini tüm küme düğümlerinde paylaşmak iyi bir fikir gibi görünüyor. Ve bu yaklaşımın uygulamanızın mimarisinde bazı değişiklikler gerektirmesine rağmen buna değer - dengeleyici kaldırılır ve tüm küme hataya daha dayanıklı hale gelir. Sunuculardan birinin ölümü, tüm sistemin çalışmasını hiç etkilemez.
Bildiğimiz gibi, oturum verileri süper küresel bir dizide depolanır. $_SESSION diskteki bir dosyaya veri yazan ve bu dosyadan veri alan . Bu disk bir sunucuda bulunuyorsa, diğer sunucuların buna erişimi olmadığı açıktır. Birden fazla makinede nasıl kullanılabilir hale getirebiliriz?
İlk olarak, şunu unutmayın PHP'de oturum işleyicisi geçersiz kılınabilir. Kendi oturum işleme sınıfınızı uygulayabilirsiniz.
Oturumları depolamak için bir veritabanı kullanma
Kendi oturum işleyicimizi kullanarak bunları veritabanında saklayabiliriz. Veritabanı ayrı bir sunucuda (hatta bir kümede) olabilir. Genellikle bu yöntem iyi çalışır, ancak gerçekten yüksek trafikle, Veritabanı bir darboğaz haline gelir(ve eğer veritabanı kaybolursa, performansı tamamen kaybederiz), çünkü her biri oturum verilerini yazmaya veya okumaya çalışan tüm sunuculara hizmet etmesi gerekir.
Dağıtılmış dosya sistemi
Tüm sunucuların oturum verilerini yazabileceği bir ağ dosya sistemi kurmanın iyi olacağını düşünebilirsiniz. Böyle yapma! Bu, veri bozulmasına ve hatta kayıplara yol açan çok yavaş bir yaklaşımdır. Herhangi bir nedenle hala bu yöntemi kullanmaya karar verirseniz, size GlusterFS'yi öneririm.
memcached
Oturum verilerini RAM'de depolamak için memcached'i de kullanabilirsiniz. Ancak bu güvenli değildir, çünkü boş alan biterse memcached'deki verilerin üzerine yazılır. Muhtemelen merak ediyorsunuz, RAM makineler arasında bölümlenmemiş mi? Tüm kümeye nasıl uygulanır? Memcached, farklı makinelerde bulunan RAM'i tek bir havuzda birleştirme yeteneğine sahiptir..
Ne kadar çok makineniz varsa, bu bellek havuzuna o kadar fazla ayırabilirsiniz. Makinelerin tüm belleğini bir havuzda toplamanız gerekmez, ancak her makineden havuza istediğiniz miktarda bellek bağışlayabilirsiniz ve bağışlayabilirsiniz. Yani, b bırakmak mümkündür hakkında Belleğin çoğu normal kullanım için ve önbellek için yalnızca oturumları değil, diğer ilgili bilgileri de önbelleğe alacak bir yığın ayırın. Memcached harika ve yaygın bir çözümdür.
Bu yaklaşımı kullanmak için php.ini dosyasını biraz düzenlemeniz gerekir.
session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"
redis kümesi
Redis - NoSQL veri deposu. Veritabanını RAM'de saklar. Memcached'den farklı olarak, kalıcı veri depolamayı ve daha karmaşık veri türlerini destekler. Redis kümelemeyi desteklemiyor, bu nedenle yatay ölçekleme için kullanmak biraz zordur, ancak bu geçicidir ve küme çözümünün alfa sürümü zaten yayınlanmıştır.
Diğer Çözümler
Toplam
Gördüğünüz gibi PHP uygulamalarının yatay ölçeklenmesi o kadar kolay değil. Pek çok zorluk vardır, çoğu çözüm birbirinin yerine geçemez, bu yüzden birini seçmeli ve sonuna kadar buna bağlı kalmalısınız, çünkü trafik ölçek dışına çıktığında, sorunsuz bir şekilde başka bir şeye geçmenin bir yolu yoktur.
Umarım bu küçük rehber, projeniz için bir ölçeklendirme yaklaşımı seçmenize yardımcı olur.
Makalenin ikinci bölümünde, hakkında konuşacağız. veritabanı ölçeklendirme.
) Merhaba! Ben Alexander Makarov ve beni Yii çerçevesinden tanıyor olabilirsiniz - geliştiricilerinden biriyim. Ayrıca tam zamanlı bir işim var - ve bu artık bir başlangıç değil - seyahat eden Stay.com.
Bugün yatay ölçekleme hakkında konuşacağım, ama çok çok genel anlamda.
Ölçekleme nedir? Bu, kaynak ekleyerek projenin verimliliğini minimum sürede artırmak için bir fırsattır.
Tipik olarak, ölçeklendirme kodu yeniden yazmak anlamına gelmez, ancak sunucu eklemek veya mevcut olanın kaynaklarını artırmak anlamına gelir. Bu tip dikey ve yatay ölçekleme olarak ikiye ayrılır.
Dikey, daha fazla RAM, disk vb. eklendiğinde. mevcut bir sunucuya ve yatay olan, veri merkezlerine daha fazla sunucu kurulduğunda ve sunucular zaten bir şekilde orada etkileşime girdiğinde.
Sorulan en havalı soru, bir sunucuda her şey benim için iyi çalışıyorsa neden gerekli? Aslında, ne olacağını kontrol etmeniz gerekiyor. Yani, şimdi çalışıyor, ama o zaman ne olacak? İki harika yardımcı program vardır - ab ve siege, olduğu gibi, sunucuyu kırmaya başlayan, sayfa istemeye çalışan, bazı istekler gönderen bir rakip kullanıcı bulutunu yakalar. Onlara ne yapmaları gerektiğini söylemelisiniz ve yardımcı programlar bunun gibi raporlar oluşturur:
Ana iki parametre şunlardır: n yapılacak istek sayısıdır, c eş zamanlı isteklerin sayısıdır. Böylece rekabeti test ederler.
Çıktıda RPS alıyoruz, yani. sunucunun işleyebildiği saniyede kaç kullanıcıya dayanabileceğinin netleşeceği istek sayısı. Elbette her şey projeye bağlıdır, farklı şekillerde gerçekleşir, ancak genellikle dikkat gerektirir.
Bir parametre daha var - Yanıt süresi - sunucunun sayfaya ortalama olarak verdiği yanıt süresi. Farklı olabilir, ancak yaklaşık 300 ms'nin norm olduğu ve daha yüksek olanın çok iyi olmadığı bilinmektedir, çünkü bu 300 ms sunucu tarafından işlenir ve buna 300-600 ms daha eklenir, bunlar işlenir. müşteri tarafından, yani her şey - stiller, resimler ve dinlenme - yüklenirken zaman da geçer.
Aslında, henüz ölçeklendirme konusunda endişelenmenize bile gerek yok - sunucuya gidiyoruz, PHP'yi güncelliyoruz, %40 performans artışı elde ediyoruz ve her şey yolunda. Ayrıca Opcache'i yapılandırıyoruz, tyunim. Bu arada Opcache, Rasmus Lerdorf'un deposunda bulunabilen ve isabetleri ve ıskaları, isabetlerin PHP'nin önbelleğe kaç kez gittiğini ve ıskaların nasıl olduğunu gösteren bir komut dosyasıyla APC ile aynı şekilde ayarlar. birçok kez dosya almak dosya sistemine gitti. Tüm siteyi çalıştırırsanız veya bağlantıları kullanarak bir tür tarayıcı çalıştırırsanız veya manuel olarak dürterseniz, bu isabetler ve ıskalamalarla ilgili istatistiklerimiz olur. %100 isabet ve %0 ıska varsa, o zaman her şey yolundadır, ancak ıskalar varsa, tüm kodumuzun Opcache'e sığması için daha fazla bellek ayırmamız gerekir. Bu, yapılan yaygın bir hatadır - Opcache var gibi, ancak bir şey çalışmıyor ...
Yine de genellikle ölçeklenmeye başlarlar, ancak hiç bakmazlar, bu yüzden her şey yavaş çalışır. Çoğu zaman veritabanına tırmanıyoruz, bak - indeks yok, indeksleri koy - her şey hemen uçtu, 2 yıl daha yetecek kadar güzellik!
Yine de önbelleği etkinleştirmeniz, bellekten tasarruf etmek için apache'yi nginx ve php-fpm ile değiştirmeniz gerekiyor. Her şey harika olacak.
Yukarıdakilerin tümü oldukça basittir ve size zaman kazandırır. Bir gün bunun yeterli olmayacağı gerçeğinin zamanı geldi ve şimdiden buna hazırlanmalıyız.
Genel olarak, sorunun ne olduğunu nasıl anlayabilirim? Ya zaten bir yüksek yükünüz var ve bu mutlaka çılgınca sayıda istek vb. değildir, bu, projenizin yükle baş edemediği zamandır ve bu artık önemsiz yollarla çözülmez. Ya genişlikte ya da yukarı büyümelisin. Bir şeyler yapmak gerekiyor ve büyük olasılıkla bunun için çok az zaman var, bir şeyler icat edilmeli.
İlk kural, hiçbir şeyi asla körü körüne yapmamanız gerektiğidir, yani. mükemmel izlemeye ihtiyacımız var. İlk olarak, önbelleği etkinleştirme veya Ana'yı önbelleğe alma vb. gibi bazı belirgin optimizasyonlar için zaman kazanırız. Sonra izlemeyi kuruyoruz, bize neyin eksik olduğunu gösteriyor. Ve tüm bunlar birçok kez tekrarlanır - izlemeyi ve iyileştirmeyi asla durduramazsınız.
İzleme ne gösterebilir? Diske vurabiliriz, yani. dosya sistemine, belleğe, işlemciye, ağa ... Ve öyle görünüyor ki, her şey az ya da çok, ancak bazı hatalar düşüyor. Bütün bunlar farklı şekillerde çözülür. Diyelim ki aynı sunucuya yeni bir disk ekleyerek bir disk ile sorunu çözebilirsiniz ya da sadece dosyalarla ilgilenecek ikinci bir sunucu kurabilirsiniz.
Şu anda izleme yaparken nelere dikkat etmelisiniz? BT:
- kullanılabilirlik, yani sunucu genel olarak canlı veya değil;
- disk kaynakları, işlemci vb. eksikliği;
- hatalar.
Kaynakları izlemenize ve sonuçları çok uygun bir şekilde görüntülemenize olanak tanıyan harika araçların bir listesi:
Bu konuşma, 2015 Yüksek Yüklü Sistem Geliştiricileri Eğitim Konferansı'ndaki en iyi konuşmalardan birinin dökümüdür.Hurda! - diyorsun.
- Ebedi değerler! - cevap vereceğiz.yüksek yük genç Etiket ekle
Bir web uygulamasının artan popülaritesi ile, desteği kaçınılmaz olarak daha fazla kaynak gerektirmeye başlar. İlk başta, algoritmaları ve / veya uygulamanın mimarisini optimize ederek yükle başa çıkmak mümkündür (ve şüphesiz gereklidir). Ancak, optimize edilebilecek her şey zaten optimize edilmişse ve uygulama yine de yükle baş edemiyorsa?
Optimizasyon
İlk adım, oturup her şeyi optimize etmeyi başarmış olup olmadığınızı düşünmektir:- Veritabanı sorguları optimal mi (EXPLAIN analizi, indekslerin kullanımı)?
- veriler doğru bir şekilde saklanıyor mu (SQL vs NoSQL)?
- önbelleğe alma kullanılıyor mu?
- FS veya DB'ye gereksiz istekler var mı?
- Veri işleme algoritmaları optimal mi?
- Ortam ayarları optimal mi: Apache/Nginx, MySQL/PostgreSQL, PHP/Python?
ölçekleme
Diyelim ki optimizasyon zaten yapıldı, ancak uygulama hala yükle baş edemiyor. Bu durumda, sorunun çözümü, mevcut kaynakları artırarak uygulamanın genel performansını artırmak için onu birkaç ana bilgisayara yaymak olabilir. Bu yaklaşımın resmi bir adı vardır - "ölçeklendirme" (ölçek) uygulamaları. Daha doğrusu ölçeklenebilirlik, bir sistemin kendisine daha fazla kaynak tahsis edildikçe performansını artırma yeteneğini ifade eder. İki tür ölçeklendirme vardır: dikey ve yatay. Dikey ölçeklendirme, tek bir düğüm (ana bilgisayar) içinde kaynaklar (işlemci, bellek, disk) eklerken uygulama performansında bir artış anlamına gelir. Yatay ölçeklendirme, dağıtılmış uygulamalar için tipiktir ve başka bir düğüm (ana bilgisayar) eklenirken uygulama performansında bir artış anlamına gelir.En basit yolun, donanımı (işlemci, bellek, disk) - yani dikey ölçeklendirmeyi basitçe güncellemek olacağı açıktır. Ayrıca, bu yaklaşım uygulamada herhangi bir değişiklik gerektirmez. Ancak dikey ölçekleme çok hızlı bir şekilde sınırına ulaşır ve bundan sonra geliştirici ve yöneticinin uygulamanın yatay ölçeklendirmesine geçmekten başka seçeneği kalmaz.
Uygulama mimarisi
Çoğu web uygulaması önsel olarak dağıtılır, çünkü mimarilerinde en az üç katman ayırt edilebilir: web sunucusu, iş mantığı (uygulama), veri (veritabanı, statik).Bu katmanların her biri ölçeklenebilir. Bu nedenle, sisteminizde uygulama ve veritabanı aynı ana bilgisayarda yaşıyorsa, elbette ilk adım bunları farklı ana bilgisayarlara yaymak olmalıdır.
darboğaz
Sistemi ölçeklemeye başlarken, ilk adım, katmanlardan hangisinin "darboğaz" olduğunu belirlemektir - yani sistemin geri kalanından daha yavaş çalışır. Yeni başlayanlar için, CPU / bellek tüketimini tahmin etmek için top (htop) ve disk tüketimini tahmin etmek için df, iostat gibi banal yardımcı programları kullanabilirsiniz. Ancak, xdebug vb. gibi yardımcı programları kullanarak uygulamanın profilini çıkarmanın mümkün olacağı yük öykünmesiyle (veya JMeter kullanarak) ayrı bir ana bilgisayar tahsis edilmesi arzu edilir. Veritabanına yönelik dar sorguları belirlemek için pgFouine gibi yardımcı programları kullanabilirsiniz (bunu savaş sunucusundaki günlüklere dayanarak yapmanın daha iyi olduğu açıktır).Genellikle uygulamanın mimarisine bağlıdır, ancak genel durumda bir darboğaz için en olası adaylar veritabanı ve koddur. Uygulamanız büyük miktarda kullanıcı verisiyle çalışıyorsa, darboğaz büyük olasılıkla statiklerin depolanması olacaktır.
Veritabanı ölçeklendirme
Yukarıda belirtildiği gibi, modern uygulamalardaki darboğaz genellikle veritabanıdır. Bununla ilgili sorunlar genellikle iki sınıfa ayrılır: performans ve büyük miktarda veri depolama ihtiyacı.Veritabanındaki yükü birkaç ana bilgisayara yayarak azaltabilirsiniz. Aynı zamanda, aralarındaki senkronizasyon sorunu akut hale gelir ve bu, master / slave şemasını senkronize veya asenkron çoğaltma ile uygulayarak çözülebilir. PostgreSQL durumunda, Slony-I , eşzamansız - PgPool-II veya WAL (9.0) kullanarak eşzamanlı çoğaltma uygulayabilirsiniz. Özel bir veritabanı erişim katmanı (PgPool-II) kurarak, okuma ve yazma isteklerini ayırma ve mevcut köleler arasındaki yükü dengeleme sorununu çözebilirsiniz.
İlişkisel DBMS kullanılması durumunda büyük miktarda veri depolama sorunu, bölümleme mekanizması (PostgreSQL'de “bölümleme”) kullanılarak veya veritabanını Hadoop DFS gibi dağıtılmış dosya sistemlerine dağıtarak çözülebilir.
Ancak, büyük miktarda veriyi depolamak için, çoğu NoSQL veritabanlarının (örneğin, MongoDB) yerleşik bir avantajı olan veri parçalama en iyi çözümdür.
Buna ek olarak, NoSQL veritabanları, bir sorguyu ayrıştırma / optimize etme, veri yapısının bütünlüğünü kontrol etme vb. için bir ek yükün olmaması nedeniyle genellikle SQL kardeşlerinden daha hızlı çalışır. İlişkisel ve NoSQL veritabanlarını karşılaştırma konusu da oldukça kapsamlı ve ayrı bir makaleyi hak ediyor.
Ayrı olarak, MySQL'i JOIN-seçimleri olmadan kullanan Facebook deneyimini belirtmekte fayda var. Bu strateji, veritabanını çok daha kolay bir şekilde ölçeklendirmelerine olanak tanırken, yükü veritabanından koda aktarır; bu, aşağıda açıklanacağı gibi, veritabanından daha kolay ölçeklenir.
Kod ölçeklendirme
Kod ölçeklendirmenin karmaşıklığı, ana bilgisayarların uygulamanızı çalıştırmak için ihtiyaç duyduğu paylaşılan kaynaklara bağlıdır. Yalnızca oturumlar mı olacak yoksa paylaşılan bir önbellek ve dosyalar gerekli mi? Her durumda, ilk adım, uygulamanın kopyalarını aynı ortamla birden çok ana bilgisayarda çalıştırmaktır.Ardından, bu ana bilgisayarlar arasında yük/istek dengelemesini ayarlamanız gerekir. Bu hem TCP düzeyinde (haproxy) hem de HTTP (nginx) veya DNS'de yapılabilir.
Sonraki adım, web uygulamasının statik, önbellek ve oturum dosyalarının her ana bilgisayarda mevcut olduğundan emin olmaktır. Oturumlar için ağ üzerinden çalışan bir sunucu kullanabilirsiniz (örneğin, memcached). Bir önbellek sunucusu olarak, aynı memcached'i kullanmak oldukça mantıklıdır, ancak elbette farklı bir ana bilgisayarda.
Statik dosyalar, NFS / CIFS aracılığıyla bazı paylaşılan dosya depolarından monte edilebilir veya dağıtılmış bir dosya sistemi (HDFS, GlusterFS, Ceph) kullanılabilir.
Dosyaları bir veritabanında da saklayabilirsiniz (örneğin, Mongo GridFS), böylece kullanılabilirlik ve ölçeklenebilirlik sorunlarını çözebilirsiniz (NoSQL veritabanları için ölçeklenebilirlik sorununun parçalama nedeniyle çözüldüğü gerçeğini dikkate alarak).
Ayrı olarak, birkaç ana bilgisayara dağıtım sorununa dikkat çekmeye değer. Kullanıcının "Güncelle" yi tıklayarak uygulamanın farklı sürümlerini görmemesi için nasıl yapılır? Bence en basit çözüm, güncellenmemiş ana bilgisayarları yük dengeleyici (web sunucusu) yapılandırmasından çıkarmak ve güncellendikçe sırayla açmak olacaktır. Ayrıca kullanıcıları çerez veya IP ile belirli ana bilgisayarlara bağlayabilirsiniz. Güncelleme, veritabanında önemli değişiklikler gerektiriyorsa, en kolay yol projeyi geçici olarak tamamen kapatmaktır.
FS ölçekleme
Büyük miktarda statik veri depolamanız gerekiyorsa, iki sorun tanımlanabilir: alan eksikliği ve veri erişim hızı. Yukarıda daha önce bahsedildiği gibi, alan eksikliği sorunu en az üç yolla çözülebilir: dağıtılmış bir dosya sistemi, verileri parçalama destekli bir veritabanında depolama ve parçalamayı kod düzeyinde "manuel" olarak düzenleme.Aynı zamanda, yüksek yükler söz konusu olduğunda statik dağılımının da kolay bir iş olmadığı anlaşılmalıdır. Bu nedenle, statik dağıtmak için tasarlanmış birçok sunucuya sahip olmak oldukça mantıklıdır. Aynı zamanda ortak bir veri depomuz (dağıtılmış dosya sistemi veya veritabanı) varsa, bir dosyayı kaydederken hostu hesaba katmadan ismini kaydedebilir, sayfayı oluştururken host ismini rasgele değiştirebiliriz (I rasgele statik dağıtan web sunucuları arasındaki yükü dengeleyin). Parçalamanın manuel olarak uygulanması durumunda (yani, verilerin yükleneceği ana bilgisayarı seçmekten koddaki mantık sorumludur), yükleme ana bilgisayarı hakkındaki bilgiler ya dosyanın kendisine göre hesaplanmalı ya da dosyaya göre oluşturulmalıdır. üçüncü verilerde (kullanıcı hakkında bilgi, depolama disklerindeki alan miktarı) ve veritabanında dosya adıyla birlikte kaydedilir.
Altın Numaralar Güzel bir telefon numarası nasıl satılır
Kripto para madenciliği: basit kelimelerle nedir
En iyi dizüstü bilgisayar işletim sistemi: Eksiksiz inceleme
Sınıf arkadaşlarından müzik indirmek için programlar Sosyal ağ sınıf arkadaşlarından üzücü bir şarkı indirin
Yandex tarayıcısının mobil versiyonu