Yazılar

Kapasite onay değildir

Dağıtılmış hesaplama serisinin 2. bölümü

Dağıtılmış hesaplamayı esas olarak bir planlama problemi olarak düşünüyordum. İş var, makineler var ve sistem birini diğerinin üzerine koymaya çalışıyor. Bu açıklama makinenin sahibini dışarıda bırakıyor.

Boş durumdaki bir GPU teknik anlamda uygun olabilir ama her açıdan önemli olan biçimlerde uygun olmayabilir. Sahip iş yükünü, veriyi, güç çekişini, bakım yükünü veya riski kabul etmeyebilir. Kapasite rıza değildir.

Benim düşünüş biçimime göre yönetişim, ağ çalıştıktan sonra eklediğimiz bir şey değildir. Ağı mümkün kılan şeyin parçasıdır. Bir iş yükü hareket etmeden önce, birinin birkaç açık soruya cevap verebilmesi gerekir. Bunu kim istedi? Bu makine neden seçildi? İş yükü ile birlikte ne gelebilir? Bunu kim reddedebilir? Makine yarı yolda kaybolursa ne olur?

Bu sorular bir veri merkezinde de vardır. Fark şudur ki merkezi bir operatör çoğu soruyu tek bir idari sınır içinde yanıtlar. Operatör makinelere sahiptir veya onları kontrol eder, hizmet şartlarını belirler, işi ölçer ve hangi politikaların uygulanacağına karar verir. Makineler birçok bağımsız kişi veya kuruluşa ait olduğunda, bu kararlar artık bir arada gelmez.

Bir iş yükü birden fazla sınırı aşar

Makine uygun olabilirken iş yükü yine de yetkisiz kalabilir.

  1. İstekBir kişi bir sonuç isterHangi sonuç gereklidir ve hangi bağlam taşınabilir?
  2. YerleştirmeBir koordinatör kapasite bulurHangi makine yetenekli, ulaşılabilir ve uygun?
  3. İzinMakine sahibi hala reddedebilirBu iş sahibin bildirilen politikasına uyuyor mu?
  4. AlmaHer iki taraf da faydalı bir kayıt tutarNe çalıştı, hangi kural altında ve risk kim taşıdı?
Mevcut kapasiteyi bulmak sadece ikinci soruyu yanıtlar. Yönetişimli bir sistem dört soruyu da yanıtlamak zorundadır.

Dağıtım sadece yerleştirmeyi değil, tarafları da değiştirir

Dağıtılmış hesaplamayı bir harita olarak çizmek cazip gelmektedir: bazı işler yerel kalır, bazıları yakınında çalışır ve bazıları büyük bir uzak havuza gider. Bu harita faydalıdır ama işin nerede yapıldığını açıklar. Ona kimin otorite sahip olduğunu açıklamaz.

En azından, dağıtılmış bir iş üç farklı çıkarı içerir.

İşi isteyen kişi bir sonuç ister. Maliyeti, hızı, gizliliği ve sonucun yeterli olup olmadığını önemser.

İşi koordine eden sistem uygun kapasiteyi bulmak ve işi harekete geçirmek ister. Kullanılabilirliği, uyumluluğu ve parçaların güvenilir bir hizmete katılıp katılamayacağını önemser.

Makineleri sağlayan kişi veya kuruluşun farklı bir kaygısı vardır. Elektriği, yıpranmayı, bağlantı kurulumunu, bakımı ve güvenlik riskini taşırlar. Makinenin hiçbir zaman gerçekleştirmemesi gereken iş türleri hakkında kuralları da olabilir.

Bazen bir şirket üç pozisyonu işgal eder, bu da sınırları kaçırmayı kolay hale getirir. Gerçekten dağıtılmış bir sistemde farklı taraflara ait olabilirler. Bir planlayıcı, bir makinesi kullanma yetkisine sahip olmadan bulabilir. Bir alıcı, kapasite için ödeme yapabilir ve makineye genel bir hak kazanamaz. Bir sahip bazı kaynakları sunabilir ama onlara bağlı her şeyin kontrolünü teslim etmez.

Bu nedenle koordine edilen birimin sadece hesaplama olmadığını düşünüyorum. Belirli bir izin, yükümlülük ve başarısızlık koşulu seti altında hesaplamadır.

Bulut bunda başarısız olmuyor

Büyük bulut sağlayıcılar altyapıyı merkezi bölgelerinin ötesine taşırlar. AWS, Outposts'u müşteri sitesinde kurulmuş AWS'ye ait ve yönetilen altyapı olarak tanımlar. Azure Arc, Azure dışındaki makineleri Azure kaynaklarından birisi olarak temsil eder ve Azure araçları ile yönetilebilir. Google Distributed Cloud, Google Cloud altyapısını ve hizmetlerini veri merkezlerine ve kenar konumlarına genişletir.123

Bunlar faydalı sistemlerdir. Gecikme, veri yerleşimi, operasyonel tutarlılık ve bağlantısı olmayan ortamlar çevresinde gerçek gereksinimleri ele alırlar. Merkezi kontrol modellerinin bir gözden kaçış olduğunu düşünmüyorum. Ürünün parçasıdır.

Sağlayıcı işletme modelini kontrol ettiği için hizmatenin arkasında durabileceğini. Hangi donanımın destekleneceğine, yazılımın nasıl güncelleştirileceğine, ne telemetrinin gerekli olduğuna ve başarısızlıkların nasıl ele alınacağına karar verebilir. Müşteriler tutarlılık ve hesap verebilirlik karşılığında bazı takdir hakkından feragat ederler.

Yapmaması gereken şey, bir bulut kontrol düzlemini müşteriye yaklaştırmayı, kontrol düzleminin kendisini dağıtmakla karıştırmaktır. İlk soru coğrafi: makine nerede oturuyor? İkincisi kurumsal: makineyi, iş yükünü ve aralarındaki ilişkiyi hangi kurallar yönetiyor?

Teşvikler de farklıdır. Bir bulut sağlayıcısı daha fazla iş yükünü hizmetleri ve işletme modeli ile uyumlu hale getirmek için makul bir şekilde motive edilir. Bireysel bir makine sahibi tam tersi varsayılan isteyebilir: sahip seçtiği dar bir politikayı tatmin etmedikçe hiçbir şey çalışmaz. Her iki pozisyon da irrasyonel değildir. Farklı ilkelerden başlarlar.

Bu büyük bir sağlayıcının daha dağıtılmış bir sistem içinde hiçbir zaman katılım yapamayacağı anlamına gelmez. Eksik olan katmanın mevcut bir bulutu daha dışarıya genişleterek ortaya çıkması olası değildir. Sağlayıcı merkezli bir sistem, heterojen konumları bir sağlayıcı gibi davranmaya zorlamak için tasarlanmıştır. Sahip merkezli bir sistem, otorite farkını anlamlı bir şekilde korumak zorundadır.

Bir pazar sorununun sadece kısmını çözer

Ayrıca açık hesaplama pazarları vardır. Örneğin Akash, altyapı operatörlerinin kapasite sunduğu, fiyat belirledikleri, dağıtımlar için teklif verdikleri ve kiralamalar yoluyla ödeme aldıkları bir pazarı tanımlar.4 Gönüllü hesaplama projeleri onlarca yıldır bilimsel iş için bağımsız olarak sahip olunan makineleri koordine etmiştir.5

Yani ilginç iddia kimsenin sahip olmadığı bilgisayarları koordine etmeye çalışmadığı değildir. Bu yanlış olurdu.

Sürekli döndüğüm boşluk daha dar. Çoğu kapasite pazarı altyapıyı diğer insanlar için işletmeyi zaten kararlaştırmış bir sağlayıcı ile başlar. Sağlayıcıdan bir sunucuyu korurması, ağa açması ve pazarın kuralları altında iş yüklerini kabul etmesi beklenir. Bu bir küçük veri merkezine, bir makinenin kontrol sahibi olan sıradan bir kişiye daha yakındır ama aynı zamanda başka bir yaşamı vardır.

Katılım, kişisel, aralıklı veya sadece kısmen mevcut makinelere ulaştığında, bir kira tüm anlaşma değildir. Sahip makinenin hemen geri gelmesini isteyebilir. Bir aile onu kullanıyor olabilir. Bir iş birincil çalışması için buna ihtiyaç duyabilir. Hassas bir iş yükü uygun olabilirken başkası olmayabilir. Ağa bir GPU kullanmak izin verilmiş olabilir ama onun yanında yaşayan dosyaları, çevre birimleri veya kimliği değil.

Kullanılabilirlik bir tekliftir. Kalıcı bir teslim değildir.

Minimum yönetişim sözleşmesi

Cevabın karmaşık bir anayasa ile başladığını düşünmüyorum. Sistem meşgul olduğunda, para söz konusu olduğunda ve bir şey başarısız olduğunda gerçek kalan az sayıda hakla başlar.

Sahip neyin sınırı içinde olduğunu tanımlayabilir. Bir makine belirli bir iş için belirli bir kapasite turu sunabilmelidir. "Çevrimiçi" çok geniş bir izindir.

Sahip, işi gerçekleştiren sınırda hayır diyebilir. Ağdaki başka bir yerde belirlenen bir politika, makinenin kendisi geçerli yetki olmaksızın gelen bir iş yükünü reddedememezse yeterli değildir.

İzin sona erebilir. Katılım bir kapsama ve süreye sahip olmalıdır. Yalnızca mevcut sıra boşaldıktan sonra var olan iptal, anlamlı bir iptal değildir.

Rota yararlı bir kayıt bırakır. İsteyen, işin nerede çalıştığını ve hangi politika altında çalıştığını anlayabilmelidir. Sahip, başka birinin özel verilerinin bir kopyasını almadan neyin kabul edildiğini anlayabilmelidir.

Başarısızlığın bir sahibi vardır. Bir makine bağlantıyı keser, bir sonuç yanlışsa veya bir iş yükü anlaşmayı ihlal ederse, sistemin bilinen bir yolu olması gerekir: uygun yerde yeniden dene, yeteneği azalt, bir kişiye sor ya da dur. "Ağ bunu halletti" hesap verebilirlik değildir.

Taraflar ayrılabilir. Bir sistem, çıkış teknik olarak mümkün fakat ekonomik veya operasyonel olarak katılım anında kimsenin açıklamadığı şekillerde cezalandırılıyorsa anlamlı biçimde gönüllü değildir.

Bu ilkeler bir ağ mimarisini belirtmez. Bu kasıtlıdır. Aynı sorular, katılımcı kapasitenin bir evde, küçük bir işletmede, bir üniversitede, bölgesel bir operatörde veya geleneksel bir veri merkezinde bulunup bulunmadığı fark etmeksizin geçerlidir. Uygulama değişebilir. Haklar tanınabilir kalmalıdır.

Ekonomik durum yetkiyi takip eder.

Dağıtılmış kapasite sıklıkla yedek kapasite olarak tanımlanır, bu da onu özgür gibi gösterebilir. Öyle değildir.

Varlık zaten var, ancak yine de birisi bunun için para ödedi. Değeri düşer. Güç tüketir. Alan kaplar. Bağlantı, bakım, soğutma ve sonunda değiştirilmesi gerekir. Makine belirli saatlerde kullanılabilir durumda kalmalıysa, sahip ayrıca seçeneğinden de vazgeçmektedir. Aynı kapasiteyi iki kez kullanamaz.

Pratik ekonomik soru, dağıtımın sermaye yoğunluğunu ortadan kaldırıp kaldırmadığı değildir. Soru, sermaye yoğunluğunun nereye gittiği, her birinin hangi riskleri taşıdığı ve sistem farkı nasıl tanıdığıdır.

Standartlaştırılmış altyapı için profesyonel işletme altında bir hesaplama birimi için basit bir fiyat yeterli olabilir. Makineler ve yükümlülükler daha çeşitli hale geldikçe daha az bilgilendirici olur. İki makine aynı hesaplamayı gerçekleştirebilir ancak çok farklı kullanılabilirlik, gizlilik sınırları, gecikme, enerji maliyeti veya kurtarma davranışı sunar.

Bu, yönetişim ve ekonominin birleştiği noktadır. Daha dar bir iş sınıfını kabul eden bir makine, o sınıf için daha güvenilir olabilir. Sahibi kullanılabilirliği taahhüt eden bir makine, kapasitesi habersiz ortadan kaybolabilen bir makineden daha fazlasını sağlar. Ek işletim riski taşıyan bir katılımcı, ham iş gücünün tüm hizmet olduğu şekilde muamele görmemelidir.

Bu sistem için doğru fiyatlandırma biriminin ne olduğunu bilmiyorum. Belirteçler, saniyeler veya hızlandırıcı saatleri tek başına bunu tanımlayacağından şüpheliyim. Bu birimler etkinliği ölçer. Etkinliğin çevresindeki anlaşmanın kalitesini ölçmek zorunda değildir.

Teşvik tasarımı ayrıca açık kısayolların karşısında durmak zorundadır. Yalnızca tamamlanan işler için ödeme, sağlayıcıları reddetmeleri gereken işleri kabul etmeye teşvik edebilir. Yalnızca kullanılabilirlik için ödeme, teknik olarak mevcut ancak kullanışlı olmayan kapasiteyi ödüllendirebilir. Her kesintiyi cezalandırmak, sıradan insanları hiç katılmaktan isteksiz kılabilir.

Son durum önemlidir çünkü teşvikler sonunda davranış olur. Sistem yalnızca kullanımı ödüllendirir, her makinayı meşgul tutmaya çalışacaktır. İlan edilen kısıtlamalar altında güvenilir hizmet ödüllendir, bu kısıtlamalara saymak için bir nedeni vardır.

Dağıtım neler yapabilirdi

Burada gerçek faydalar mevcuttur, ancak hiçbiri otomatik olarak gelmez.

İş, bağlamın sahibi olan kişi veya kuruluşa daha yakın kalabilir. Bu, gecikme ve gereksiz veri hareketini azaltabilir. Gizliliği garantilemez; yazılım ve politika hala bu talebi kazanmak zorundadır.

Kapasite daha birçok yerden gelebilir. Hata alanları gerçekten bağımsız ise bu, direnci iyileştirebilir. Bin makine, tek bir kırılgan yetki aracılığıyla koordine edilir, coğrafi olarak dağıtılmış ve operasyonel olarak merkezi haldedir.

Mevcut varlıklar daha etkili kullanılabilir. Ek kullanım, güç, aşınma, destek ve koordinasyon maliyetlerini aşarsa bu, ekonomiyi iyileştirebilir. "Zaten satın alındı" "işletme maliyeti serbest" anlamına gelmez.

Sistem yerel takdir edebilirliği koruyabilir. Bu, belki de en önemli fayda olabilir ve ölçülmesi en zor olandır. Bir kişi, makinelerini başka birinin veri merkezinin bir şubesine dönüştürmeden katılabilir.

Bu faydaları gerçek kılmak için hala birkaç boşluk çalışması gerekiyor: taşınabilir politika, iş yükü kaynağı, güvenilir ölçüm, anlaşılabilir iptal, anlaşmazlık çözümü, zarif bozulma ve aynı olmayan makineler arasında hizmet kalitesini karşılaştırmanın bir yolu. Bunlar, hesaplama pazarının etrafındaki ikincil özellikler değildir. Pazarın güvenilir olabilmesi için gereken koşullardır.

Kullanacağım test

Her dizüstü bilgisayarın bir veri merkezi haline gelmesi veya merkezi altyapının değiştirilmesi gerektiğini savunmuyorum. Merkezi sistemler sıklıkla ağır iş, tutarlı kullanılabilirlik ve bir muhasebeci sağlayıcıdan faydalanan işlemler için doğru yerdir.

Soru, bunların yanında başka bir kategori varsa: sahibleri sistemde ilkeler olarak kalan makineler arasında koordine edilen hesaplamanın.

Test basit ve tatmin etmesi zor. Makine keşfedilebilir hale geldikten sonra, bir iş yükü beklediğinde ve işletmek için ekonomik bir teşvik vardıktan sonra, sahip hala sistemin geri kalanının saygı göstermek zorunda olduğu bir politika altında hayır diyebilir mi?

Cevap hayırsa, hesaplama dağıtılmış olabilir. Yetki değildir.

Dipnotlar

  1. AWS, Outposts'ı müşteri binalarına AWS altyapısı, hizmetleri, API'leri ve araçlarını genişleten, ekipmanı AWS tarafından sahip olunan ve yönetilen tam yönetimli bir hizmet olarak tanımlar: What is AWS Outposts? ↩

  2. Microsoft, Azure Arc etkinleştirilmiş sunucuları, Azure dışındaki makineler olarak tanımlar ve bu makineler Azure kaynak kimlikleri alır, yerel Azure sanal makineleri gibi yönetilir: What is Azure Arc-enabled servers? ↩

  3. Google, Dağıtılmış Bulut portföyünü Google Cloud altyapısını ve hizmetlerini veri merkezlerine ve kenar konumlarına genişleten, bağlı ve hava boşluğunda çalışan işletim modelleriyle tanımlar: Google Distributed Cloud ↩

  4. Akash, sağlayıcıların işlem gücü katkısında bulunduğu, fiyat belirledikleri ve kiracı iş yüklerini barındırarak gelir elde ettikleri merkezi olmayan bir pazaryerini tanımlar: Should I Run an Akash Provider? ↩

  5. BOINC, bağımsız olarak sahip olunan bilgisayarlar arasında bağışlanan kaynakları koordine eden, uzun süredir devam eden gönüllü hesaplama platformudur: BOINC: A Platform for Volunteer Computing ↩