Birçok yeni müşteri CloudSigma’yı kullanmaya başladığında performansı test etmek ister; genellikle bulut sunucuları ile kendi altyapıları arasındaki performans sonuçlarını karşılaştırmak isterler ve bu oldukça mantıklıdır. Kaynak bazında doğrudan bir fiyat karşılaştırması hikayenin tamamını anlatmaz; asıl önemli olan nihai sonuçtur, yani belirli bir bilgi işlem görevini gerçekleştirmenin maliyeti ne kadardır?
Belirli bir gereksinim için, bunu gerçekleştirmek için gereken kaynak sayısı bulutlar arasında büyük ölçüde farklılık gösterebilir. Bu, yalnızca fiyatları karşılaştırmanın işe yaramadığı anlamına gelir. Diğer taraftan, performansı tek başına karşılaştırmak da daha iyi değildir. Anlamlı karşılaştırmalar yapabilmek için, bilgi işlem birimi başına düşen maliyeti hesaplamak üzere hem fiyatı hem de performansı bir araya getirmek gerekir. Bu yazıda, bulut sunucularımızı ve diğerlerini karşılaştırırken edindiğim bazı düşüncelerimi paylaşacağım. Ayrıca yararlı sonuçlar elde etmek için bazı ipuçları ve bunların gerçekte ne anlama geldiğini de sunacağım.
Sağlık Uyarıları
Öncelikle açıklamak gerekirse, genel olarak performans testlerine oldukça şüpheyle yaklaşıyorum. Gerçek dünyadaki kullanıma dair nadiren gerçek bir fikir sunar. Kısacası, platformda kullanmayı planladığınız gerçek uygulamaları çalıştırmanın yerini hiçbir şey tutamaz. Bunu zaman açısından makul bir maliyetle gerçekleştirebiliyorsanız, böyle bir çalışmanın alternatifi yoktur.
Diğer bir faktör ise bulut sağlayıcısının ne kadar meşgul olduğudur. Bulut sunucularını test edip mükemmel sonuçlar alabilirsiniz. Ancak bu sonuçlar, büyük ölçüde söz konusu sağlayıcının kullanım düzeyinden (veya kullanım eksikliğinden) kaynaklanıyor olabilir. Bu olumlu bir işaret olmayabilir. Operasyondaki zorlukları, kaybedilen müşterileri, geçmişteki kullanılabilirlik ve güvenilirlik sorunlarını vb. yansıtabilir. Bu nedenle, performans testi sonuçlarını yorumlarken bulut sağlayıcısını geçmiş kesintiler ve diğer potansiyel sorunlar açısından her zaman araştırmalısınız.
Son bir sağlık uyarısı olarak, performans dikkate almanız gereken tek faktör değildir. Çoğu zaman daha düşük performans, altında yatan daha sağlam (ve yedekli) bir donanım mimarisini yansıtabilir. Bu nedenle, bulutun hangi altyapı üzerine kurulduğunu çok net bir şekilde anlamak her zaman önemlidir. Böylece, sonuçları adil bir şekilde karşılaştırabilir ve anlamlı bir satın alma kararı verebilirsiniz.
Sorunu tanımlayın
Bu yazının ilerleyen kısımlarında, performansın çeşitli yönlerini ve sonuçları en iyi nasıl yorumlayacağınızı açıklıyorum. Ancak herhangi bir performans testi yapmadan önce, bulutta gerçekleştirmek isteyeceğiniz bilgi işlem türünü tanımlamak önemlidir; bu, farklı performans metriklerinin göreceli önemini belirleyecektir. Örneğin, bir veritabanı sunucusu yerleştirmek istiyorsanız ve bu sunucu yoğun okuma erişimi altında ancak düşük yazma erişimine sahip olacaksa, buluttaki disk performansına ve özellikle ardışık olmayan okuma erişimine dikkat etmelisiniz.
Bu nedenle, herhangi bir bulut sunucusu performans testine başlamadan önce, buluttan neyi iyi bir performans olarak kabul edeceğinizi fiilen belirleyin. Hangi yönlerin kilit öneme sahip olduğunu ve bilgi işleminizin gerçek dünyadaki performansı üzerinde orantısız bir etkiye sahip olduğunu belirlemelisiniz. Bu konuda net bir fikre sahip olduğunuzda, performans testlerine bakmaya başlayacak durumda olursunuz.
Hesaplama Performansı
Ham hesaplama performansına baktığımızda CPU ve RAM’den bahsediyoruz. Bulutlar arasında saf hesaplama düzeyindeki performans farkları aslında o kadar da büyük değildir. Ancak gerçek farklara neden olan bazı faktörler vardır.
Buluttaki hesaplama performansını etkileyen açık ara en büyük faktör paylaşımdır. Genel bulutlar çok kiracılı ortamlardır. RAM ve depolama alanı aslında aşırı tahsis edilemez (aşırı satılabilseler de), ancak CPU edilebilir ve edilmektedir. Paylaşım seviyeleri önemli ölçüde değişir, ancak esasen genel bulut sağlayıcıları fiziksel bir ana bilgisayarın CPU kapasitesini %100’den fazlasına satabilirler.
En büyük sağlayıcılardan bazıları, üç katın üzerinde CPU sıkışma oranları kullanır. Bu, aynı fiziksel makinedeki tüm sanal sunucuların toplam ‘satılan’ CPU kapasitesinin, gerçek CPU kapasitesinin üç katı olabileceği anlamına gelir. Bunu yaparlar çünkü çoğu sanal sunucu, zamanın büyük bölümünde kendilerine ayrılan CPU'nun %100'ü gibi bir oranı kullanmaz. Yine de sıkışma oranları, bulut sunucularının performans testlerini ve gerçek dünyadaki kullanımını doğrudan etkileyecektir. Sıkışma yüksekse (yani %200'den fazla CPU tahsisinde), bulut sunucusu performansı önemli ölçüde düşecektir.
Basitçe söylemek gerekirse, herhangi bir fiziksel makinedeki yük çekirdek başına 1'den fazla olursa, hesaplama görevleri sıraya alınır ve o sanal makinenin işi tamamlama süresi uzar. Çoğu bulut sağlayıcısının kapasite/saat bazında ücretlendirme yaptığı göz önüne alındığında, bu durum o bulutun müşterileri için doğrudan bir maliyet etkisi yaratır.
Hesaplama performansını etkileyen diğer önemli faktör, sanal makinenin erişebildiği CPU çekirdeği sayısıdır. Bu tüm uygulamalar için geçerli bir faktör değildir ancak birçok modern uygulama çoklu iş parçacığı desteği sunar. Bu durum, uygulamanın ve/veya işletim sisteminin hesaplama görevlerini birden fazla çekirdeğe yayabilmesi anlamına gelir. Hesaplama performansınızı artırmak için harika bir ipucu, bir uygulamanın destekleyebileceği iş parçacığı (yani çekirdek) sayısını, sanal makinenin erişebildiği çekirdek sayısıyla eşleştirmektir.
Maalesef bu, birçok genel bulutta mümkün değildir. Bunun nedeni, sanallaştırma platformlarının CPU çekirdeği düzeyinde sanallaştırmayı desteklememesidir. Başka bir deyişle, her bir çekirdek aynı anda yalnızca bir sanal makine tarafından kullanılabilir. CPU çekirdeklerinin sanallaştırılmasını destekleyen bulutlarda, toplam CPU boyutunu aynı tutarken o makine için çekirdek sayısını değiştirmeyi denemelisiniz.
Örneğin, 2GHz'lik bir makineniz varsa, kullanılan çekirdek sayısını ikiden dörde çıkarmanın performans testinizi nasıl etkilediğini görebilirsiniz. Bunu yaparak, o sanal makinede çalışan uygulamalar görevleri aynı anda dört çekirdek üzerinden yürütebilecektir. Bizim durumumuzda, bir sanal makinenin kullandığı çekirdek sayısını, web konsolumuzun sunucu detay modalındaki ‘gelişmiş’ sekmesinden ayarlayabilirsiniz. Kullanılan çekirdek sayısını manuel olarak değiştirmeden önce bulut sağlayıcısının standart çekirdek boyutunun ne olduğunu her zaman kontrol etmeyi unutmayın. Bizim durumumuzda çekirdek başına 2.2GHz'dir ancak bu durum buluttan buluta değişiklik gösterir.
Şunları kullanmayı düşünmenizi öneririm: POV-RAY, CoreMark, Dhrystone veya Whetstone bulut sunucularının performansını test etmek için.
Depolama: gerçek bulut sunucusu performans testi
Tüm performans, bir darboğazın oluştuğu en zayıf halka ile sınırlıdır. Günümüzde teknoloji, CPU ve RAM kullanımı açısından sanallaştırma alanında önemli ölçüde ilerlemiştir. Örneğin, tek bir fiziksel makine sanallaştırılabilir ve toplam genel performansta minimum kayıpla birden fazla bulut sunucusuna sahip olabilir. Ne yazık ki depolama söz konusu olduğunda, hala kat edilmesi gereken çok yol var. Sonuç olarak, çoğu durumda buluttaki sanal sunucuların performansı, o bulutun depolama çözümünün performansı tarafından belirlenir.
Kısacası depolama, şu anda buluttaki çoğu hesaplama görevinin performansı üzerindeki sınırlayıcı faktördür. Saf hesaplama görevleri için pov-ray ve diğer performans testleri hangi sonuçları üretirse üretsin, gerçek şu ki sanal sunucunun fiziksel depolama disklerinden veri alma ve bu disklere veri yazma hızı, şu anda bir bulut sunucusunun gerçek dünyadaki performansını belirleyecektir.
Bunu akılda tutarak, buluttaki performansta görülen gerçek farklılıklar, hesaplama görevleriyle ilgili olsa bile, genellikle depolama performansındaki farklılıklardan kaynaklanma eğilimindedir. Bu yazıda daha önce de belirtildiği gibi, hesaplama görevine bağlı olarak çok farklı müşteri ihtiyaçları vardır. Bu durum, depolama konusunda her zamankinden daha geçerlidir. Büyük sıralı veri bloklarına (akış ortamı gibi) mı yoksa küçük, dağınık bilgi parçalarına mı (belki de büyük bir veritabanında) hızlı okuma erişimine ihtiyacınız var? Büyük patlamalar halinde periyodik olarak erişilen, hızlı değişen veriler için yoğun yazma erişimini sürdürmeniz mi gerekiyor? Çok sayıda senaryo vardır ve her biri aynı platformda farklı performans gösterecektir.
Temelde, performanstaki farklılıklar mimariye dayanır. Mimarideki bu farklılıklar genellikle verilerin depolanması, yedekliliği ve dolayısıyla aslında geri dönülemez bir şekilde kaybolma olasılığı açısından farklı sağlamlık derecelerinden kaynaklanır. Üst düzeyde, bulutlar ya Depolama Alanı Ağı (SAN) ya da daha dağıtık yerel depolama çözümleri kullanır. Bunlarda depolama, her bir fiziksel makine üzerinde yer alır.
İyi SAN'ler doğası gereği yüksek düzeyde yerleşik yedekliliğe sahiptir. Ancak, hesaplama görevleri için verilerin SAN'den ağ üzerinden sanal makinenin CPU ve RAM’ine gönderilmesi gerektiğinden performans düşer. Sonuç olarak, SAN tabanlı bulutlar, yerel dağıtık depolama çözümlerine sahip bulutlara kıyasla benzer koşullarda daha düşük bir performans gösterme eğilimindedir. SAN'in bir diğer dezavantajı da çok büyük bir tek hata noktası oluşturmasıdır. SAN'ler son derece güvenilirdir. Eğer ciddi bir şekilde arızalanırlarsa (ki arızalandıkları olmuştur), o zaman çok büyük bir kesinti ve veri bozulmasıyla karşı karşıya kalmanız muhtemeldir.
SAN kullanan çoğu bulut sağlayıcısı, büyük ölçüde maliyet nedenleriyle, kurumsal ortamlarda kullanılan türden tam yedekli hata devretme çözümleri kullanmaz. Her SAN’in eşit olmadığını fark etmek ve bulut sağlayıcısının SAN’leri ile ne düzeyde bir yedeklilik kullandığını anlamak önemlidir.
Yerel depolama tabanlı bulutlar iyi disk performansı gösterme eğilimindedir. Ancak, genellikle yalnızca kalıcı olmayan biçimde yerel depolama sunarlar. Bu, kalıcı depolama ile adil bir karşılaştırma değildir. Geçici depolamanın, kalıcı depolama ile aynı şekilde arızalara karşı sağlam olması gerekmez. Anlamlı sonuçlar elde etmek için kalıcı depolamayı her zaman kalıcı depolama ile karşılaştırmak önemlidir.
Dağıtık yerel depolama çözümlerine sahip bulutlara bakarken, hangi yedekliliğe sahip olduklarını da bilmeniz gerekir. Sabit disk sürücüleri önemli bir oranda arızalanır ve bu nedenle depolama yöntemi kritiktir. Çoğu sağlayıcı bir tür RAID kullanır ancak güvenlik seviyeleri çok farklıdır. Düşük uçta, iki diskin esasen birbirini aynaladığı RAID1 bulunur. Bu genellikle iyi bir performansa sahiptir. Ama bir disk arızalandığında, yedek disk eski diskteki tüm verileri kopyalayana kadar, ikinci (yoğun yüklü) disk de arızalanırsa veriler tamamen kaybolma riskiyle karşı karşıya kalır. Ayrıca, RAID1 dizisinin herhangi bir yeniden oluşturulması sırasında, disk performansının normalden çok daha düşük olması muhtemeldir.
Bu nedenle birçok sağlayıcı RAID5 (tek disk arızasına karşı dayanıklı) veya RAID6 (iki disk arızasına karşı dayanıklı) kullanır. RAID6, yerel depolama için açık ara en güvenli çözümü sunar ancak performanstan büyük bir ödün verilmesini gerektirir. Bizim yaklaşımımız RAID6 kullanmak, ancak bunu sınıfının en iyisi donanımsal RAID denetleyici kartlarıyla birleştirmektir. Bunlar büyük bellek önbelleklerine sahiptir ve pil desteklidir. Kullandığımız RAID denetleyici kartları aslında tüm disk dizilerinden önemli ölçüde daha pahalıdır. Böylece, RAID6 depolamanın sunduğu çok büyük güvenlik ağını sunmaya devam ederken, çok daha az dayanıklı kurulumlarla karşılaştırılabilecek bir performans sunabiliyoruz. Son derece şeffaf olduğumuz bulut altyapısı kurulumumuz hakkında daha fazla bilgi edinin.
Disk performansı kıyaslamaları için IOzone veya Bonnie++ kullanmanızı öneririm.
Dolayısıyla, depolama kıyaslama testi sonuçlarını yorumlarken aşağıdaki bilgilere de sahip olduğunuzdan emin olun:
- bulut hangi depolama mimarisini kullanıyor (yerel, SAN, diğer)?
- veri için hangi hata toleransı (fail-over) ve yedeklilik önlemleri yürürlükte?
- kıyaslama testi yaptığım depolama geçici mi yoksa kalıcı mı?
Bu üç sorunun yanıtlarını kıyaslama testi sonuçlarıyla bir araya getirmek, size gerçek depolama performansı hakkında oldukça iyi bir fikir verecektir.
Ağ Bağlantısı
Ağ performansını belirlemek ve ölçmek, hesaplama ve disk performansına göre önemli ölçüde daha kolaydır. Ağ performansının iki temel yönü vardır: gecikme süresi ve bant genişliği.
İhtiyaçlarınıza bağlı olarak, bulut sağlayıcısının kullandığı ağın gecikme süresi önemli olabilir veya olmayabilir. Bulutu büyük ölçüde kendi kendine yeten işlemler için kullanıyorsanız, gecikme süresinin bir öncelik olması pek olası değildir. Ancak, bulut dışındaki dünyayla etkileşim kuran gerçek zamanlı uygulamalar çalıştırıyorsanız, gecikme süresi kritik bir performans belirleyicisi olacaktır.
Genellikle gecikme süresinin büyük bir kısmı tamamen fiziksel mesafeden kaynaklanır. Örneğin, Londra ile San Francisco arasındaki gecikmenin çoğu aslında ışığın bu mesafeyi kat etmesi için geçen süredir. Gecikme süresindeki farklılıklar, izlenen rotanın değişen verimliliğine göre belirlenir. Buluttan buluta farklılık gösteren yön de budur. Rotanın verimliliği, bulutun doğrudan bağlantıya sahip olduğu ağ sağlayıcılarının doğrudan bir sonucudur. Bu, onlardan IP bağlantısı alınarak veya eşleme (peering) yoluyla gerçekleşir. Gecikme sürelerine bakarken bulut sunucunuza kolayca ping atabilir ve performansını belirleyebilirsiniz. Ancak, gerçek son kullanıcılarınız ile bulut sunucunuz arasındaki performansı belirlemek önemlidir.
Kullanıcılarınızın çoğu tek bir coğrafi bölgedeyse veya erişim öncelikle şirketinizin merkez ofisinden sağlanacaksa, performansı bu konumlardan test etmek önemlidir. Şunun gibi ticari hizmetler: Pingdom dünya çapında aynı anda çok sayıda genel konumdan gecikme süresini belirlemek için uygun maliyetli bir yol sunar.
Bulut sunucunuzun ulaşabileceği gerçek bant genişliği de oldukça önemlidir. Daha geleneksel barındırma çözümlerinin aksine, bulut sağlayıcıları ücretlendirmeyi toplam veri aktarımı hacmine göre yapma eğilimindedir. Diğer bir deyişle, size 7/24 sabit bir bağlantı seviyesi sunan Mbit başına modeldeki gibi zamana bağlı değildir. Buna rağmen, birçok bulut sağlayıcısı herhangi bir sanal sunucunun bant genişliğini ‘sınırlayacaktır’. Bu durum, siz o sınıra ulaşana kadar kullanıcı tarafından fark edilmeyecektir. Eğer oldukça dalgalı bir bant genişliği profiliniz varsa, bu durum dikkate alınması gereken önemli bir performans faktörü olabilir.
Bulut sunucunuzun gerçek bant genişliğini test etmek için, kendi tarafında aktarım hızını kısıtlamayan bir kaynaktan bulut sunucusuna veri indirmeyi denemek önemlidir. Mevcut hızı belirlemenin harika bir yolunun, Microsoft, Ubuntu gibi büyük bir sağlayıcıdan büyük bir dosya indirmek veya daha da iyisi işletim sistemini yamalamak olduğunu görüyorum. Bu, genellikle aynı anda çeşitli konumlardan birçok farklı dosya indirme eğilimindedir. Bağlantınızın hızı hakkında size oldukça iyi bir fikir verecektir.
Standart bir test olarak genellikle ana sitelerinden bir Fedora live CD indiririm, ancak en azından her zaman birkaç farklı dosya ve konumla denemeler yapmalısınız. Kendi çok hızlı kurumsal ağınıza sahip olmakta ısrar ediyorsanız, bunun yerine test olarak bulut sunucunuzdan kendi ağınıza bir dosya indirmek isteyebilirsiniz.
Şimdi Sonuçları Ağırlıklandırmak İçin Fiyatlandırmayı Tekrar Ekleyin
Yukarıdaki yöntemleri kullanarak, çeşitli bulut sunucusu sağlayıcılarının nasıl bir performans gösterdiği hakkında iyi bir fikir edinebilmelisiniz. Ayrıca, özel ihtiyaçlarınız için en önemli olan hangi yönlere odaklanmanız gerektiğini de bilmelisiniz.
Son adım, kıyaslama sonuçlarına bir fiyatlandırma boyutu eklemektir. Bunun için bir formül yoktur. Bu, yukarıdaki çeşitli yönlerin göreceli performansına bağlıdır ve bunları siz belirlersiniz. Bir bulut %40 daha iyi performans gösteriyorsa (sizin tarafınızdan belirlendiği üzere) ancak yalnızca %30 daha pahalıysa, o zaman açıkça cazip görünür. Benzer şekilde, büyük bir bant genişliği ihtiyacınız varsa, daha düşük bilgi işlem performansı, rekabetçi bir veri aktarımı fiyatlandırma planı ile geride bırakılabilir. Doğru kararı vermenin anahtarı, tüm bu çeşitli faktörleri bir araya getirmektir.
Son olarak, kıyaslama, hangi bulut sunucularının sizin için doğru olduğunu belirlemeye yönelik daha büyük bir sürecin parçası olmalıdır. Bu, diğer yönleri de içermelidir. Örneğin bunlar; hizmet seviyesi anlaşmalarını, veri/sağlayıcı bağımlılığı hususlarını, fiziksel konumu ve yasal yetki alanını içerebilir. Tüm bu yönleri bir araya getirerek, doğru bulut bilişim sağlayıcısı seçimini yapmak için kendinizi konumlandırmış olursunuz.
Yorumlar
Henüz yorum yapılmamış. İlk siz olun.