Bulut bilişimde esneklik , o bulutun uygulama ihtiyaçlarına mümkün olduğunca çabuk uyum sağlama yeteneğidir. Yazarlara göre, bazıları Ölçeklenebilirlik ve esneklik kavramlarını özdeş, bazıları ayrı olarak kabul eden birkaç tanım vardır . Bu tür dağıtılmış sistemlerin gelişi (bkz. Dağıtılmış Hesaplama ) kaçınılmaz olarak düzenlenmesi veya sınırlandırılması gereken teknik sorunları içerir. Ekonomik olarak, esnekliğin gelişinin müşteriler ve bulut sağlayıcıları üzerinde etkisi oldu. Örneğin, tedarikçiler talep üzerine kullanılan kaynaklar için ödeme yapmak üzere bir "kullandıkça öde " ödeme sistemi oluşturmuşlardır. Böylece bir müşteri kısa süreliğine ve istenilen büyüklükte sunucu kiralayabilir.
Amazon Web Services , Microsoft Azure ve hatta Google App Engine gibi birçok sağlayıcı , isteğe bağlı olarak bulut sunucuları oluşturmuştur. Ancak her bulut sağlayıcısının hız, esneklik, gecikme vb. açısından kendine has özellikleri vardır.
Esneklik ve ölçeklenebilirliğin eşanlamlı olarak düşünülmesi yaygındır. Buluttaki esneklik, bir malzemenin esnekliğinin fiziksel özelliği ile karşılaştırılabilir; bu, geçirdiği deformasyondan sonra orijinal şekline geri dönme yeteneğidir. Böylece esneklik, bulutun maruz kalabileceği basıncın, maruz kaldığı basınca oranı olarak hesaplanabilir.
Ancak, NR Herbst ve Doaa M. Shawky gibi diğerleri iki çok farklı tanım yapar:
ölçeklenebilirlik Ölçeklenebilirlik, bir sistemin eylemlerinin hızını, süresini, sıklığını veya ayrıntı düzeyini hesaba katmadan kaynak gereksinimlerini karşılama yeteneğidir. esneklik Esneklik, bir sistemin, tedarik edilen kaynaklar sistemin talebiyle eşleşecek şekilde kaynakları otomatik olarak tedarik ederek ve tedarikten çıkararak taleplere uyum sağlama derecesidir.Ölçeklenebilirlik bu nedenle esneklik için bir ön koşuldur. Zaman, esneklik ve ölçeklenebilirlik arasında önemli bir bağlantıdır: sistemin uyum sağlaması ne kadar az zaman alırsa, o kadar esnek olur.
Buluttaki esnekliğin tüm amacı, bir uygulamanın kaynak talebine mümkün olduğunca kesin bir şekilde yanıt vermektir. Bunun için sistemler birkaç dakika içinde uyum sağlayabilmektedir.
Esnekliğe iki yaklaşım vardır. Birincisi yatay esneklik olarak adlandırılır. Bu esneklik biçimi , istemci örneğine sanal makineler eklenerek veya kaldırılarak elde edilir . Dikey olarak adlandırılan ikinci yaklaşım artık sunucular eklenerek değil, makineye RAM , CPU vb. gibi kaynaklar eklenerek gerçekleştirilmektedir .
Genel bir kural olarak, sanal makinenin oluşturulmasını ve başlatılmasını beklemeniz gerektiğinden, yatay esneklik dikey esnekliğe göre daha yüksek bir zaman maliyetine sahiptir. Böylece daha iyi performans için dikey esneklik kullanılacaktır. Sorun, bu tür bir yaklaşımın yatay ölçeklenebilirlikten çok daha sınırlı olmasıdır. Aslında dikey ölçeklenebilirlik, fiziksel makinenin dışındaki kaynaklara yayılamaz. Bu nedenle, dikey olarak mümkün olduğunca uzun süre ölçeklenebilmek için sanal makinenin başlangıçta hangi makinede başlatılacağının net bir şekilde tanımlanması gerekir.
Chien-Yu Liu makalesinde, kendisine göre en verimli olan, yatay esnekliğin neredeyse sonsuz ölçeklenebilirliğini ve dikey esnekliğin hızını birleştiren bir algoritma tanımlamaktadır: Sanal makine sıfır olduğunda sanal makine kaynaklarını artırmak. yeterince uzunsa, aynı bulut üzerinde yenilerini oluşturmak gerekir (yatay esneklik). Tek bir bulut kaynak taleplerini karşılayamazsa, diğer bulutlardan sanal makineler eklenmelidir (yatay esneklik). Bulut artık talepleri karşılamadığında bir sonraki uygulamaya geçmeniz gerekir.
NR Herbst, makalesinde, bize yukarıdan aşağıya ve aşağıdan yukarıya esnekliği hesaplamanın bir yolunu sunuyor, aynı zamanda aşırı ve yetersiz sağlanan bir bulut sisteminin doğruluğunu da sunuyor. Böylece, yukarı (sırasıyla aşağı) esneklik, yetersiz tedarik edilen (sırasıyla fazla tedarik edilen) bir optimal durumda (sırasıyla ) harcanan ortalama zamanla, eksik tedarik edilen kaynakların birikmiş miktarının ortalaması ile ters orantılıdır (sırasıyla aşırı tedarik) test süresi boyunca (sırasıyla ):
Artan (sırasıyla azalan) Kesinlik, yetersiz sağlanan kaynakların (sırasıyla fazla sağlanan) (sırasıyla ) birikmiş miktarı ile test süresi arasındaki orandır :
Bulut sistemlerinin esnekliği, satıcılar için bazı zorluklar yaratır. Birincisi, birkaç temel konfigürasyonun olmasıdır, hangisini seçeceğinizi bilmek genellikle oldukça zordur. Amaç, en ucuz olurken en iyi konfigürasyona sahip olmaktır. Bu adım tamamlandığında, uygulamanın süre için az çok önemli istekleri olacaktır. Sistemi nasıl ve ne zaman sağlamalı/sağlamadan çıkarmalı? Bu adımda amaç, altyapı (euro) ve geçiş (zaman) maliyetlerini en aza indirmektir.
Buluttaki en büyük zorluklardan biri, çok büyük dağıtılmış sistemlerdeki hataları gidermektir. Çok büyük sistemlerle ilgili problemler olduğundan, bunları daha küçük sistemlerde çözmek imkansızdır, bu nedenle testler doğrudan üretim ortamlarında yapılır. Sanal makineleri kullanmak bir çözüm olabilir. Gerçekten de, fiziksel makinelerde mümkün olmayan bir sanal makinede değerli bilgileri yakalamak mümkündür. Ne yazık ki, tüm satıcılar, ya sanallaştırma çağından önce başladıkları ya da karşılayamayacaklarını düşündükleri için bir VM kullanmadan tekliflerini geliştirdiler.
Diğer bir zorluk, depolamanın esnekliğini yönetmektir. Bu soruyu yanıtlamak için, sunulan performans garantileri, istek ve depolama API'lerinin zenginliğine göre değişen birçok girişimde bulunuldu. Buradaki fikir, bulutun esnekliğinin avantajlarını korurken, yalnızca dayanıklılık, yüksek kullanılabilirlik ve verileri yönetme ve sorgulama yeteneği ile ilgili olarak programcıların beklentilerini karşılamak değildir.
Bulutların esnekliğini ve ekolojisini birbirine bağlayan zorluklar da vardır . Gerçekten de, bulutta barındırılan uygulamaların kullanılmayan kaynakları mümkün olduğunca serbest bırakması önemlidir. Birincisi, beklemedeki bir bilgisayar, kaynaklarının "yalnızca" üçte ikisini tükettiği ve bu da çok fazla enerji tasarrufu sağladığı için ve ikincisi, sektör çok zayıfken çevre üzerinde daha olumlu bir etki anlamına geldiği için. Bunun için sağlayıcılar , kullanıcıları kaynakları mümkün olan en kısa sürede boşaltmaya teşvik etmek için ayrıntılı (kullandıkça öde ) faturalandırma sistemini oluşturdu.
Yazılım lisansları da bir sorundur. Gerçekten de, bazı yazılım sağlayıcıların henüz bulut için teklifleri yok, bu da astronomik yazılım lisans maliyetleri anlamına geliyor. Bu sorunu çözmek için açık kaynak çok popüler bir çözümdür. Neyse ki, Amazon veya Microsoft gibi bazı satıcılar “kullandıkça öde ” yazılım lisanslama teklifleri sunmaya başlıyor . Örneklerini ücretli bir yazılım yapısı üzerinde çalışır rağmen, açık kaynak çözümleri (sırasıyla için çok ilginç bir alternatif olmaya devam $ 0.15 karşı / s $ 0.10 / saat).
Esneklik, talebe yanıt olarak bilgi işlem kaynaklarının dinamik olarak edinilmesini veya serbest bırakılmasını mümkün kıldığı için, bunların izlenmesi ve kontrol edilmesi önemlidir. İzlenecek veriler üç boyutta sınıflandırılır: maliyet, kalite ve kaynaklar. Çerçeve Mela olarak izlemek ve hizmetlerin esnekliğini analiz etmek bulut . Bunun kontrolü için SYSBL (Simple Yet Beautiful Language) gibi araçlar üç seviyede kontrole sahip olmayı mümkün kılar: uygulama seviyesinde, bileşen seviyesinde ve programlama seviyesinde ve ayrıca esneklik gereksinimlerini karşılamak.
Dikkat edilmesi gereken bir diğer konu da sanal makinelerin başlangıç zamanıdır. Gerçekten de, zamanında ve kullanıcılar için kullanıma hazır olmalıdırlar. Bu başlatma zamanı farklı faktörleri hesaba katabilir: günün saati, işletim sistemi görüntüsünün boyutu, bulut sunucusu türü, veri merkezlerinin konumu ve aynı anda talep edilen örnek sayısı.
Her sistemin sınırları vardır. Bulut söz konusu olduğunda , esnekliğinin ilk tanımlanabilenlerinden biri mevcut kaynakların sayısıdır, diğer sınırlar bulunmuştur.
Doaa M. Shawky tarafından yapılan testlere göre, bir seferde ne kadar çok makine tahsis ederseniz, sistem o kadar az esnektir. Gerçekten de, bir deney sırasında, aynı stres değerlerine sahip iki sistemi karşılaştırdı, biri paket başına makine sayısını 10, ikincisi partiler halinde 20 artırdı. Ortalama d süresinin iki deneyin uzantısı 4427.2 olduğu ortaya çıktı. sırasıyla saniye ve 6334.4 saniye. Aynı zamanda, ortalama esneklik sırasıyla 0.0036 ve 0.0028 idi. Sistemin esnekliğinin yatay olarak yapılması durumunda, tahsis edilen makine sayısı arttıkça esneklik de azalmaktadır. Bunun nedeni uzatma süresinin artmasıdır. Bu sınır, yatay esneklik için daha da doğrudur çünkü somutlaştırmak için her sanal makinenin başlatılmasını ve başlatılmasını beklemek gerekir.
Bulutun esnekliğinden dolayı tedarikçi sistemlerin sistemlerinden yararlanma oranı %5 ile %20 arasındadır. Sonuç olarak, bir veya daha fazla müşteriden güçlü bir kaynak talebi gelmesi durumunda her zaman kullanılabilir kaynaklar vardır.
Tedarikçiler, bulut maliyetlerindeki değişiklikler yoluyla fiyatlarını değiştirmelerine izin verir : bunlar arasında işlemciler, bellek, sabit disk ve ağ gibi donanımların satın alınması ve bakımı da yer alır. Müşteri tarafından kiralanırken, belleğin boyutu, kullanılan disk alanının boyutu ve veri aktarım maliyeti de dikkate alınır.
Amazon EC2, müşterilerine iki iş modeli sunar:
Spot bulut sunucuları teklifi sayesinde Amazon, müşterilerini yoğun olmayan dönemlerde bulutlarını kullanmaya teşvik ediyor , sonunda şirket bulutlarının kullanım eğrisini düzleştirmek istiyor, bu da bakım maliyetlerini azaltacak.
Bulutun kullanımı, esnekliği nedeniyle bir müşteri için çeşitli avantajlara sahip olabilir:
Örneğin, büyük hesaplamalar yapması gereken bir başlangıç, 1000 Amazon EC2 makinesini bir saat boyunca kullanmak için 1 makineyi 1000 saat kullanmakla aynı fiyatı ödeyecektir.
Aynı şekilde zaman içinde çok değişkenlik gösteren bir kullanım söz konusu olduğunda bulut kullanmak ilgi çekicidir. Birçok tedarikçinin sunduğu “kullandıkça öde” teklifinin esnekliği sayesinde, müşteri yalnızca kullandığı kadar öder. Örneğin, yoğun saatlerde 500 sunucu kullanan ancak yoğun olmayan dönemlerde yalnızca 100 sunucu kullanan ve gün içinde ortalama 300 sunucu kullanan bir müşteri durumunda. Bulut olmadan müşterinin 500 sunucuya veya saatte 500 x 24 = 12.000 sunucuya sahip olması gerekirdi. Bulut ve esnekliği sayesinde yalnızca 300 x 24 = 7.200 sunucu saati kullanır.
Ancak bu analiz, bulutun alışılmadık bir kaynağa, örneğin Aralık ayındaki çevrimiçi satış sitelerine yönelik bir talebe hızlı bir şekilde uyum sağlamasına izin verdiği gerçeğini dikkate almıyor. Buradaki etki çok az, oysa müşteri sitelerini kendileri barındırsaydı, yeni sunucular sipariş etmek ve kurmak birkaç hafta sürebilirdi, tatiller geçtikten sonra sunucularının 'daha yararlı olmayacağı' gerçeğinden bahsetmiyorum bile .
2010 yılında genel bulut sağlayıcıları arasında bir karşılaştırma yapıldı : Amazon AWS, Azure, AppEngine ve CloudServers Bu sağlayıcılar 4 kriter etrafında değerlendirildi: küme esnekliği , kalıcı depolama, bulut içi ağ ve geniş ağlar.
Yasal nedenlerle, genel bulut sağlayıcılarının kimliği sonuçlarda anonimleştirilir ve C1'den C4'e kadar belirlenir.
sunucu boyutu | yapılandırma | Maliyet / saat | maliyet / çekirdek |
---|---|---|---|
Amazon EC2 | |||
küçük | 1 ECU, 1.7 GB ram, 160 GB disk alanı | 0.085 dolar | 0.085 dolar |
uzun boylu | 4 ECU, 7.4 GB ram, 850 GB disk alanı | 0,34 dolar | 0.085 dolar |
orta - hızlı | 5 ECU, 1.7 GB ram, 350 GB disk alanı | 0.17 $ | 0.034 $ |
XL | 8 ECU, 15 GB RAM, 1,7 TB disk alanı | 0,68 $ | 0.085 dolar |
XL-hızlı | 20 ECU, 7 GB ram, 1.7 TB disk alanı | 0,68 $ | 0.034 $ |
Özel bulut | |||
küçük | 1 çekirdek, 2,8 GHz , 1 GB ram, 36 GB disk alanı | 0.11 $ | 0.11 $ |
yol | 2 çekirdek, 3.2 GHz , 2 GB ram, 146 GB disk alanı | 0.17 $ | 0.085 dolar |
uzun boylu | 4 çekirdek, 2 GHz , 4 GB ram, 250 GB disk alanı | 0,25 dolar | 0.063 dolar |
hızlı | 4 çekirdek, 3 GHz , 4 GB ram, 600 GB disk alanı | 0,53 dolar | 0.133 $ |
XL | 8 çekirdek, 2 GHz, 8 GB ram, 1 TB disk alanı | 0,60 dolar | 0.075 dolar |
Sağlayıcı | Örnek türü | Çekirdek sayısı | Fiyat |
---|---|---|---|
C1 | C1.1 | 1 | 0.085 $ / saat |
C1.2 | 2 | 0,34 $ / saat | |
C1.3 | 4 | 0.68 $ / saat | |
C2 | C2.1 | 4 | 0,015 $ / saat |
C2.2 | 4 | 0.03 $ / saat | |
C2.3 | 4 | 0,06 $ / saat | |
C2.4 | 4 | 0.12 $ / saat | |
C3 | varsayılan olarak | Yok | 0.10 $ / CPU sa |
C4 | C4.1 | 1 | 0.12 $ / saat |
C4.2 | 2 | 0.24 $ / saat | |
C4.3 | 4 | 0.48 $ / s | |
C4.4 | 8 | 0,96 $ / saat |
Her kullanım için bir sunucu kümesi yüklenir. Sağlayıcılar arasında iki tür yük modeli vardır: IaaS (AWS, Azure ve CloudServers), örneğin tam olarak kullanılıp kullanılmadığına bakılmaksızın ayrılan süreye dayalı bir yük; PaaS (AppEngine), kullanıcı uygulamasının günlük aşırı CPU tüketimine dayalı yükleme .
Sunucu kümeleri, bir kullanıcının kullanılan örnek sayısını dinamik olarak artırabilmesi veya azaltabilmesi anlamında da "esnek"tir. AppEngine, "opak ölçeklemeyi" destekleyen AWS, Azure ve CloudServer'dan farklı olarak bu değişikliği şeffaf bir şekilde gerçekleştirir.
Kümelerin esnekliğini değerlendirmek için 3 test yapıldı:
Karşılaştırma yürütme süresi Benchmarking geleneksel mimarilerine benzer, çünkü kıyaslama görevlerinin yürütülme süresini ölçer. Kıyaslama görevleri bir performans stres testi makinenin tüm kaynakların (üzerinde işlemci , bellek ve disk) Maliyet her Kıyaslama görevini gerçekleştirme maliyeti "Ölçeklendirme" gecikmesi bu, istemcinin kaynağı talep etmesi ile yeni bir eşgörünüm tahsis etmesi arasında geçen süredir. "Ölçeklendirme" gecikmesi, bir uygulamayı dağıtmanın performansını ve maliyetini etkileyebilir.Testler için kümelerin performansları karşılaştırılır ( kıyaslama , kıyaslama başına maliyet ve ölçekleme gecikmesi ).
Hizmet | Ameliyat |
---|---|
tablo | al, koy, sorgula |
damla | indirme yükleme |
Kuyruk | göndermek, almak |
Depolama hizmetleri, bir uygulamanın durumunu ve verilerini korur ve API çağrıları aracılığıyla örneklere erişilebilir. Depolama işlemleri için 2 ekonomik model bulunmaktadır. Amazon AWS ve Google AppEngine tarafından sunulan hizmetler , bir depolama işlemini gerçekleştirmek için tüketilen CPU döngülerini temel alır ve bu da karmaşık istekleri daha pahalı hale getirir. Azure ve CloudServers, isteğin karmaşıklığından bağımsız olarak işlem başına sabit bir maliyete sahiptir.
Tedarikçileri depolama açısından karşılaştırmak için 3 test yapıldı:
operasyonların tepki süresi bir depolama işleminin yürütme süresini ölçer. Yapılan işlemler tüm tedarikçiler tarafından desteklenmekte ve müşteriler tarafından sıklıkla kullanılmaktadır. Bunlar basit okuma/yazma işlemleri, veritabanlarının performansını test etmeye yönelik SQL sorgularıdır.Sağlayıcı | almak | koymak | sorgu |
---|---|---|---|
C1 | 0.13 | 0.31 | 1.47 |
C3 | 0.02 | 0.23 | 0.29 |
C4 | 0.10 | 0.10 | 0.10 |
Sağlayıcı | daha küçük örnek | en büyük örnek |
---|---|---|
C1 | 773.4 | 782.3 |
C2 | 235.5 | 265.7 |
C4 | 327.2 | 763.3 |
Sağlayıcıların performansını ağ düzeyinde karşılaştırmak için bulut içi ağda ve geniş alan ağlarında testler yapıldı .
Bulut içi ağ , bir müşterinin örneklerini birbirine ve bir bulut tarafından paylaşılan hizmetlere bağlar . Bulut içi bir ağın performansını karşılaştırmak için yol kapasitesi ve gecikme süresi ölçümleri alınır.
Geniş alan ağı , bir buluttaki veri merkezlerini birbirine ve internetteki harici ana bilgisayarlara bağlar . Satıcılar, gecikmeyi azaltmak için bir müşterinin uygulamalarını barındırmak için birden çok bölge sunar. AppEngine, istek üzerine yakın bir tarih merkezini otomatik olarak seçmek için DNS hizmeti sunarken, diğer sağlayıcılar manuel yapılandırma gerektirir. Geniş bir alan ağı için optimum gecikme, en uygun konum ile bir tedarikçinin herhangi bir veri merkezi arasındaki minimum gecikme ile tanımlanır . Bu nedenle testleri karşılaştırma kriteri, optimal bir noktada mevcut olan veri merkezlerinin sayısı olacaktır .
: Bu makale için kaynak olarak kullanılan belge.