Railway'nin kendi veri merkezini kurma hikâyesi
(blog.railway.com)- Railway, GCP tabanlı altyapının fiyatlandırma, destek ve özellik geliştirme açısından kendisini sınırladığını düşünerek, daha doğrudan kontrol edebileceği fiziksel altyapı projesi Railway Metal'ı başlattı
- Ocak 2024'te başladıktan sonra ilk sunucunun bağlanmasına kadar 5 ay, kullanıcı iş yüklerinin alınmasına kadar ise ek 3 ay geçti; 9 ay sonra Kaliforniya'daki ilk site devreye girdi
- Alan kiralamaktan daha büyük kısıtın güç ve soğutma olduğu görüldü; Railway, Greenfield ya da rack bazlı kiralama yerine Cage Colocation modelini seçti
- Ağ tarafında bölge başına en az 2 ISP, tam internet yönlendirme tablosu, IP prefix bazlı rota seçimi ve çoklu zone tasarımıyla tek veri merkezi arızasına karşı hazırlık yapıldı
- Rack yerleşimi, kablo dokümantasyonu, PDU, ters hava akışlı switch'ler, Redfish API, PXE, FRR ve SONiC gibi konularla doğrudan ilgilenmek gerekiyor; kendi bulutunu kurmak, Terraform dağıtımından çok ev inşa etmeye benziyor
GCP'den Railway Metal'a geçişin nedeni
- Railway'nin altyapısı en başından beri Google Cloud Platform üzerinde kuruluydu
- GCP, ilk büyüme döneminde faydalı oldu ancak operasyon büyüdükçe müşterilere istedikleri platformu sunmada sınırlar ortaya çıktı
- Hyperscaler tabanlı işletim modeli, Railway'nin sunabildiği fiyatı, hizmet seviyesini ve özellik geliştirme kapsamını doğrudan sınırlıyordu
- egress fee fiyatlandırmayı etkiliyordu
- Üst katmandaki altyapıda sorun çıktığında kök nedeni anlamak çoğu zaman mümkün olmuyordu
- Yılda milyonlarca dolar harcansa bile alınan destek seviyesinin, 100 dolar harcamaktan çok farklı olmadığı düşünülüyordu
- Railway buna karşılık 2024'te Railway Metal projesini başlattı
- 9 ay sonra Kaliforniya'daki ilk siteyi devreye aldı
- Cage içindeki fiber kablolardan ISP sözleşmelerine kadar tasarım, teknik tanım ve kurulumu doğrudan kendisi yaptı
- Ek olarak 3 veri merkezi region'ını daha açıyor
İlk alan seçimi: veri merkezi cage'i
- Railway Metal projesi Ocak 2024'te başladı ve ilk sunucunun bağlanması 5 ay sürdü
- Kullanıcı iş yüklerini donanım üzerine almak için uygun olduğuna karar verilmesi ise 3 ay daha aldı
- Kendi altyapısını kurmak için sunucuların yerleştirileceği alan, kararlı güç ve yeterli soğutma gerekiyor
- Temel olarak üç seçenek vardı
- Greenfield buildout: veri merkezi satın almak ya da kiralamak
- Cage Colocation: bir işletmecinin veri merkezinde tel örgüyle çevrili özel bir alan edinmek
- Rack colocation: colocation veri merkezinde tekil rack ya da rack'in bir kısmını kiralamak
- Railway, dört duvarı, güvenlik kapısını ve geri kalan her şeyi kendisinin tasarlayabildiği boş bir alan elde etmek için Cage Colocation seçeneğini tercih etti
- Alanın kendi maliyeti çok büyük olmasa da, asıl büyük kalem güç ve buna bağlı soğutma maliyetiydi
- Bölgeye göre kW başına maliyet büyük değişiklik gösterebiliyor
- ABD'nin batısında, Singapur'un yarısından daha düşük fiyatlar görülebiliyor
- Güç, gerçek tüketimden bağımsız olarak anlık kullanılabilirliği garanti eden aylık sabit commit ile ödeniyor
Güç tasarımı ve PDU
- Railway, GCP'de kullandığı kapasiteyi karşılamak için önce hedef vCPU sayısını, RAM GB ve NVMe TB miktarını belirledi
- Bu sayılara göre sunucular ve CPU'lar seçildi
- Temel değişken, belirli bir güç tüketimi içinde istenen işlem yoğunluğunu sığdırabilen güç yoğunluğu idi
- Güç hesabı yalnızca watt toplamaktan ibaret değil; özellikle 3 fazlı beslemede daha da karmaşık hale geliyor
- Cloudflare'in 3 fazlı güç ve PDU'lara giriş yazısı bu konuyu ele alıyor
- Veri merkezinde güç en kritik kaynaklardan biri ve elektrik kesintisinin toparlanma süresi çok uzun olabiliyor
- Her rack için tamamen bağımsız 2 güç feed'i gerekiyor
- Normalde iki feed yükü birlikte paylaşıyor
- Feed'lerden biri devre dışı kalsa bile sistemin çalışmayı sürdürmesi gerekiyor
- Gücü sunuculara dağıtmak için Power Distribution Unit gerekiyor
- Temel PDU'lar aslında gelişmiş bir çoklu priz gibi
- Railway'nin kullandığı PDU'lar tek tek priz kontrolü ve ölçüm yapabiliyor
- Her PDU'ya ağ üzerinden erişilebiliyor ve her priz uzaktan ölçülüp kontrol edilebiliyor
Ağ: ISP'ler, yönlendirme ve bölgesel rotalar
- Bulut makineleri tek başına var olmadığından ağ kritik rol oynuyor
- Railway, düşük gecikme için dış dünyaya güçlü şekilde bağlı veri merkezi tesisleri aradı
- Tercih ettiği koşullar şunlardı
- Tier 1 ISP ile on-network durumda olmak
- Internet Exchange içinde yer almak
- Yakındaki diğer veri merkezlerine bağlanabilecek fiber altyapıya sahip olmak
- Railway üzerinde dağıtılan uygulamalar çok farklı uç noktalarla iletişim kuruyor
- Sidney'deki bir ev internet kullanıcısı
- ABD'de AWS sunucularında barındırılan bir API
- Düşük gecikme ve düşük bant genişliği maliyeti için Railway, kullanım senaryosuna göre optimize edilmiş birden fazla internet sağlayıcısıyla sözleşme yaptı
- ISP'ler, hedef bölgelerdeki ağ olgunluğuna göre seçildi
- Yanlış ISP ile çalışmak, belirli hedef pazarlara giderken ek ağ hop'ları oluşturarak gecikmeyi artırabiliyor
- En kötü durumda oldukça karmaşık ağ yolları oluşabiliyor
- Her bölgede, bölgesel footprint'e göre en az 2 ayrı ağ seçildi
- Bağlantı sağlandıktan sonra her ISP'den tam internet yönlendirme tablosu alınıyor ve ağ switch'lerinde bunlar birleştirilerek IP prefix bazında en iyi rota belirleniyor
- Avustralya'daki bir kullanıcı Singapur'da dağıtılmış bir uygulamaya erişirse paketler büyük olasılıkla Telstra'ya veriliyor
- Aynı uygulama Japonya'daki kullanıcı ya da sunuculara paket gönderirse büyük olasılıkla PCCW tercih ediliyor
- Peering bilgileri herkese açık ve ağlar arası bağlantılar bgp.tools üzerinden görülebiliyor
- Yedeklilik için her region içinde birden fazla zone kuruluyor ve siteler arası bağlantı da ölçekleme açısından önemli görülüyor
- dark fiber veya wavelength service gibi seçenekler değerlendiriliyor
- Amaç, veritabanı aynı odada da olsa 4 blok ötedeki komşu binada da olsa uygulamanın farkı hissetmemesi
- Bu tasarım, tekil veri merkezi arızalarına karşı dayanıklılığı artırmayı hedefliyor
Rack'ler, koridorlar, soğutma ve kablo güzergâhları
- Veri merkezlerinde rack'ler sıralar halinde yerleştirilir ve aralarındaki koridorlar hava akışı için kullanılır
- Cold Aisle tarafına tesisten soğuk hava verilir; sunucular bu havayı içeri çeker ve arka taraftaki Hot Aisle'a sıcak hava olarak atar
- Verimlilik için Cold Aisle ile Hot Aisle arasındaki havanın birbirine karışmaması gerekir
- Rack'ler 19 inç genişliğinde ekipman kullansa da yükseklik, genişlik ve derinlik ekipman ve kablo ihtiyaçlarına göre seçilebilir
- Çoğu sunucu ekipmanı bakım için raylar üzerinde öne çekilebildiğinden, cage ölçülerinin buna izin vermesi gerekir
- Kablolar ve kablo yönetimi de alan istediği için, rack'leri ne kadar sık dolduracağınız ile cage içine kaç rack sığdıracağınız arasında ödünleşim oluşur
- Railway'nin deneyiminde gerçek fiziksel alandan çok güç ve soğutma daha sık kısıtlayıcı oldu
- Yeni sitelerde, kabloları egzoz yolundan uzak tutup hava akışını iyileştirmek için 800 mm genişliğinde daha geniş rack'ler seçildi
- Rack'lerin dışında, güç ve veri taşımak için üst yapı ve kablo tavaları da gerekiyor
- Fiber, cage'in kenarından her rack'e yönlendiriliyor
- Rack'ler arası kablolar da ayrıca çekiliyor
- Bu kalemler bazen veri merkezi işletmecisinin cage teklifine dahil olabiliyor
- Railway, rack başına switch-to-server fiber kablo yoğunluğu yüksek olduğu için portları rack'in arkasına bakan reverse airflow switch'ler satın aldı
- Bunlar ağ portlarının bulunduğu tarafa doğru egzoz yapan switch'ler
- Kablo tavaları buna göre hizalanarak tüm kablolamanın rack'in tek bir tarafında yapılması sağlanıyor
- Böylece kabloların rack'in önünden arkasına zikzak çizmesi önleniyor
Kurulum dokümantasyonu ve rack-and-stack
- Railway ilk başta kablolamayı kendi yapmayı denedi ancak sonuçlar tutarsız oldu; doğru kurulum için uzmanlar devreye alındı
- Kurulum uzmanlarının neyin nereye yerleştirileceğini anlayabilmesi için kapsamlı bir dokümantasyon paketi gerekiyordu
- Tipik dokümanlar iki gruba ayrılıyor
- Cabling matrix: her kablonun iki ucundaki cihaz konumunu, portu, kablo özelliklerini, fiber tipini ve uzunluğu tanımlar
- Rack elevation: rack içindeki her ekipmanın konumunu ve yönünü görsel olarak gösterir
- Railway'nin her kurulum aşamasında 60'tan fazla ekipman, 300'den fazla ayrı kablo ve onlarca ince ayrıntı bulunuyordu
- Kurulum ve devreye almanın temelini oluşturan yazılı teknik tanımlar ve elektronik tablolar elle hazırlanıyordu
- Malzemeler sahaya ulaştıktan sonra tüm kurulumu tamamlamak yaklaşık 6–14 gün sürüyordu
- Sonrasında Railway, build specification üretimini otomatikleştiren dahili araçlar geliştirdi
- Veri merkezi cage'i kurmak, tipik bir yazılım, DevOps ya da Terraform stack dağıtımından çok uzak; daha çok ev inşa etmeye benziyor
- Veri merkezi tesisi, yükleniciler ve tedarikçiler arasında, aynı organizasyon içinde bile yöntemler biraz değişebildiği için operasyonel olarak çok ayrıntılı dikkat gerekiyor
Sahada karşılaşılan istisnalar ve fiziksel sorunlar
- Bir sitede PDU ters monte edilmişti ve güç zeminden geldiği için planlanan priz numaraları tersine dönmüştü
- Amsterdam sahasında, özel bir demarcation point yerine dış fiber hattının doğrudan rack içindeki bir kutuya girdiği bir tesis yapısı vardı
- Bazı tesislerde güç prizleri diğer sahalardan farklı olarak phase-to-neutral kablolanmıştı; başka yerlerde ise phase-to-phase kullanılıyordu
- Bir yüklenici, ağ ekipmanlarının reverse airflow olduğunu fark etmeyip ters yönde monte etmeye çalıştı ve bu yüzden veri kablolarının kısa olduğunu düşündü
- Bazı kablolarda bağlantının gelmemesinin nedeni fiber polarity hatasıydı; Railway bu sırada “rolling fibre cables” kavramını öğrendi
- Bu, LC connector uçlarını çıkarıp yer değiştirme yöntemidir
- Bir tedarikçinin yaklaşık 24 PDU'sunda priz kusuru vardı; güç fişleri düzgün oturmuyor ve ciddi fiziksel güç uygulansa bile sorun çözülmüyordu
Fiziksel kurulumdan sonraki yazılım işleri
- Donanım yerleştirildikten sonra işler daha tanıdık olan yazılım alanına geçiyor
- Gerekli işler şunlar
- BGP yapılandırması
- OS kurulumu
- izleme yapılandırması
- ağ ekipmanı yapılandırması
- router yapılandırmalarının yazılması
- RIR yani bölgesel internet kayıtlarının güncellenmesi
- Sunucuların ve PDU'ların özel denetleyicilerine erişmek için Redfish APIs kullanılıyor
- Sunucuları ağ üzerinden başlatmak için PXE kullanılıyor
- Railway'nin ağ tasarımı, FRR ve SONiC çalıştıran whitebox network switch'leri kullanıyor
- Bu tasarımla, Railway control plane ile derin biçimde entegre yalnızca L3, yazılım odaklı bir ağ kuruluyor
- Son aylarda Railway, yeni yazılım araçları Railyard ve MetalCP'yi geliştirdi
- yeni cage tasarımı
- kablo takibi ve görselleştirme
- sunucu OS kurulumu
- sunucuyu internete bağlama sürecine kadar tek tıklamalı deneyim sunan araçlar
- Sonraki yazıda, bir odadaki sunucu grubunun çalışan bir Railway zone'una nasıl dönüştürüldüğü ele alınacak
1 yorum
Hacker News yorumları
Deneyimlerime ve bu tür yazılara bakınca Google’ın müşterisi olmasından hoşlanmadığı hissine kapılıyorum.
Biri “public cloud yapmalıyız” diye karar vermiş ve yapmışlar, ama müşterileri 3 metrelik bir sırıkla uzaklaştırmak istiyor gibiler.
AWS hesap yöneticisinin, gerekirse çamurun içinde sizinle birlikte yuvarlanacak biri olduğundan %100 eminim. Kriz anında rica etseniz yerde sizinle birlikte uyuyacak kişidir.
Buna karşılık Google Cloud tarafındaki kişilere bakınca üzülüyorum. Çünkü onların da Google içinde bizden daha az sevildiği ve daha az desteklendiği görülüyor. Kendi şirketini doğru düzgün satış yapmaya ve hizmet vermeye ikna etmeye çalışan birini görmek üzücü; sanki başarısız olması için ayarlanmışlar.
Microsoft tarafındaki insanlar kurşun geçirmez gibi sağlam; satışta iyi, hizmet sunumunda iyi ve cebimdeki tüm parayı alırken bile bunun benim için iyi bir şey olduğuna beni sonuna kadar inandırıyorlar. Ama cloud’ları çok tuhaf bir… şey.
Railway’in bare metal’e geçmesine gelince, yaklaşık 15 yıl bunu yapmış biri olarak asla, asla, asla geri dönmek istemem. Buna değmez. Ama sanırım insanın bunu bizzat yaşaması gerekiyor; bu yol zaten böyle.
Yakında Google’ın neden o kadar zorlandığını anlayacaklar. Ancak Borg ya da yapay beyinler yapmak yerine insanlara hizmet satmayı gerçekten çok istiyorlarsa Google’dan 100 kat daha iyi yapabilirler.
Yine de çamurun içinde birlikte yuvarlanacaklarını sanmıyorum; bu biraz şaşırtıcı. Acaba çamurda eşlik etme seviyesine gelmek için ne kadar harcamak gerekiyor?
Tüm cloud hizmeti, cloud computing’i hiç bilmeyen ve yalnızca “bare metal sunucu kiralama”yı bilen biri tarafından tasarlanmış gibi hissettiriyor. Evet cloud computing, ama cloud computing kavramının kendisini çökerten bir biçimde.
GCP komut satırı aracı
gcloudda daha iyi tasarlanmış hissi veriyor.Böylece aylarca süren ön çalışmadan tasarruf edebilirdik.
Kişisel deneyimime göre Google Cloud desteği, 3 kişilik küçük bir ekibin çok az harcama yaptığı durumda bile bize oldukça iyi davrandı; başka bir şirkette Microsoft da bize çok iyi davrandı. Ancak o dönemdeki harcama ölçeği muhtemelen veri merkezi elektrik şebekesi izleme sistemlerinden bile takip edilebilecek düzeydeydi.
Buna karşılık AWS bir özellik hakkında yalan söyledi ve sonunda hiç cevap bile vermedi.
Üst yönetimle zorunlu, milyonlarca dolarlık AWS sözleşmelerini konuşan hesap yöneticileri, o yöneticilerle nasıl konuşmaları gerektiğini iyi biliyor gibi görünüyor.
Ama gerçekten başkaları için ürün geliştirip sunma aşamasına geldiğimizde, tozun içinde yalnız bırakılan biz olduk.
Daha da komik olan, yalan söyledikleri o özelliğin son kullanıcı deneyimini mükemmel kılmak için kritik olduğu şeklinde satılmış olmasıydı.
Destek biletine cevap yazdım ama yanıt gelmedi; iki AWS temsilcisine e-posta attım, onlardan da yanıt gelmedi.
Eski Rackspace günlerini hatırlattı. Gerçekten savaş gibi çok olay yaşanmıştı.
EMC’den gelenler test amaçlı depolama ekipmanı kurmaya gelmişti; birbirlerinin ayağına dolanıp komedi filmi gibi koca bir sunucu rack’ini devirdiler. Tabii ki sözleşmeyi alamadılar.
Bir kamyon şoförü kalp krizi geçirdi ve kaza yüzünden DFW veri merkezi offline oldu. Böyle durumları engellemek için babalar vardı ama henüz içlerine çimento doldurulmamıştı.
Bir ara yolun karşısındaki başka bir binaya lazerle bant genişliği göndererek geçici bağlantı kurmuştuk.
Bir gün sunucu kelimenin tam anlamıyla yanmaya başladı; camı kırıp kutu tipi fan aldık.
Veri merkezi mühendisliği ilk dönemlere göre epey ilerledi. O zaman Facebook ile birlikte OpenCompute Project üzerinde çalışıyorduk; o günün ölçülerine göre çok ileri altyapı fikirleri vardı.
Ana mikrodalga bağlantı, veri bağlantı katmanının derinlerinde aralıklı paket hatalarıyla sürekli kopuyordu. Araştırınca yolun karşısındaki ağacın yapraklandığını, dalların da bizim binadaki ekipmanın görüş hattına doğru sallanıp girdiğini gördük. Bir merdiven, bir testere ve 10 dakika ile bağlantıyı geri getirdik.
Veri merkezinden dışarı çıkan ana BGP yönlendiricisi sürekli yeniden başlıyordu. Yedekli ekipman yoktu. Kontrol edince veri merkezi sıcaklığının çok yüksek, soğutmanın da çok kötü olduğunu; emiş fanı tarafındaki hava sıcaklığının 60°C’yi geçtiğini gördük. Geçici olarak fanı ona doğru çevirdik.
Birkaç hafta sonra başka bir odadaki klima da pes etti ve Nortel DMS-100’ün üstüne su püskürtmeye başladı. Kendi switch’ine sahip bir dial-up ISP’ydi. Suyun elektrik taşıyabileceğini düşündüğüm için silmeye yardım etmek istemiyordum ama mecbur kaldım.
Sonra küçük, uzak bir adada da çalıştım; internetin ana bağlantısı GS uydusu üzerinden 1MB/s’lik bir linkti ve ping 500 ms’nin üzerindeydi. Yerel halk, 9600 baud olarak sınıflandırılmış mikrodalga telefon ağı üzerinden dial-up yapıyordu; nasıl olduysa 56k modem çalışıyordu.
Bir gün bir Solaris kutusunda kritik bir
.sodosyasının eksik olduğunu fark ettim; ne yerel yedek vardı ne de kurulum medyası. İngiltere’deki bir arkadaşımı arayıp bir kopyayı FTP sunucusuna yüklemesini istedim ve o kutuyu tekrar online hâle getirdim.Birkaç yıl sonra Manchester’da Oxford Road üzerinde, o dönem Avrupa’nın en yoğun otobüs hattının üstünden bir lazer link kurup ofis ile üniversite kampüsünü birbirine bağlamıştık. Eğlenceli zamanlardı.
Hepsi inanılmaz eğlenceliydi ama şimdi neredeyse sadece yazılımla uğraştığım için gerçekten memnunum.
Sunucu kelimenin tam anlamıyla yanmamış olsa da, cam açıp fan kullanma işi 2024 Ocak’ında Chicago’daki Equinix CH1 veri merkezinde de yaşandı. Azure ExpressRoute çöktü.
Duyduğuma göre hava fazla soğuduğu için CRAC dayanamamış. Yeterince serin tutmak için tüm kapı ve pencereleri açık bırakmışlar ama sonunda başarısız olmuşlar. CRAC giderse sunucular da onunla gider.
O switch kesinlikle lanetliydi. Aynı haftanın ilerleyen günlerinde aynı ekipmanda spanning tree yapılandırma hatası oldu; LINX birkaç saat durdu ve Birleşik Krallık ISP peering’inin yarısı geçici bir karmaşaya girdi. O projede yer alan diğer kişilerin hepsi de 2 yıl içinde hayatını kaybetti.
Birkaç yıl sonra tesisi gezerken, altında yerde hâlâ kızarmış cesedin durduğunu gördüm.
Yazıdaki “yılda milyonlarca dolar harcasanız da 100 dolar harcayan biri kadar destek alıyorsunuz” kısmı can yakıcı. Google için oldukça büyük bir sorun.
Bu yazıyı özellikle eğlenceli buldum çünkü Blekko altyapısını kurarken benzer maceralar yaşamıştık.
Blekko gibi rack’ler arası trafiği, yani internetle giden-gelen trafikten çok doğu-batı trafiği olan şirketlerde, fiziksel olarak birlikte konumlandırılmış servislerin başka sunucularla bant genişliği için rekabet etmemesi şarttı; SoftLayer’da, yani IBM’in bağlı bulutunda bu özel kullanım için maliyet ödemekten çok daha ekonomikti.
Soğuk koridoru çevreleyen kapalı yapı kuran oldukça güzel şirketler de var. Temelde zeminden çıkan tüm soğuk havanın sunucuların arka tarafına girmesini ve başka yerlere kaçmamasını sağlıyor. Yanlardan daha az soğuk havanın sunuculara çekilmesini de engelliyor.
Veri merkezlerinde HVAC CRAC kapasite hesabı da ilginç. İlk colocation tesisimizde kafesimizin yanındaki zemin alanına genişleme için önalım hakkımız vardı; ama gerçekten genişleme zamanı geldiğinde tesisin soğutma kapasitesi kalmamıştı, bu yüzden hiçbir anlamı yoktu.
Bu süreçleri yaşayınca 0xide çözümünü çok daha iyi anlayacaksınız.
Hakim bir şirket böyle kurulur. Sizi hyperscaler’lara kilitleyen sızlanan genel kabulleri görmezden gelmeleri iyi olmuş.
Bir altyapı şirketiyseniz sattığınız bare metal’e kendiniz sahip olmalısınız. Aksi hâlde sadece bir bulut aracısısınız ve egress maliyeti 0 dolar olan bare metal rakipleri tarafından her an fiyatla ezilme riskiniz var.
Colocation ve peering ile egress maliyeti 0 dolara indirilebildiği için Cloudflare ücretsiz plan sunabiliyor; yeni bir oyuncu bulut servislerini yeniden satarak Cloudflare ile rekabet edemez.
Aslında hyperscaler’lar için bant genişliği kazığı sadece bir gelir kaynağı değil, aynı zamanda hendek. AWS üzerinde bir sonraki AWS’nin kurulmasını engelliyor ve IaaS’in üstünde “PaaS” diye tamamen yeni ve stratejik olarak daha zayıf bir pazar segmenti yaratıyor.
Bununla o maliyeti yarıya indirebilir, depolama maliyetini de düşürebilir ve “koltuk başına” fiyatlandırmayı kaldırabiliriz.
Gerçekten heyecan verici.
Oldukça iyi bir yazı. Aklıma gelen bir şey şu: Raf yönetimi için kurum içi aracı neden kendileri geliştirmişler? NetBox zaten var
NetBox harika; 2000’lerin ortasında 50’den fazla rafı yönetirken elimizde olsaydı keşke
https://github.com/netbox-community/netbox
Ama kendi yaptığımız araç olan Railyard’ın iyi uymasının nedeni, tüm yazılım, donanım ve orkestrasyon yığınımızla derinlemesine entegre olması
Açık kaynak araçların sorunu, fazla genel amaçlı olmaları. Sorunu çözmek yerine, sorunu o aracın veri modeline uyacak şekilde bükmek zorunda kalıyorsunuz
Sonunda bu aracı Railway’in kendisine entegre etmemiz çok olası. On-prem’e geçmek istiyorsanız, tek düğmeyle donanım tasarımı, devreye alma, dağıtım ve geliştirici deneyimi sunmak gibi. Oxide’ın yaptığına benzer, ama ters taraftan yaklaşan bir şey
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox, “ağ altyapısı için gerçekliğin kaynağı (source of truth)” olmak istiyor
Her duruma göre önemli olan şeyler değişir; ama NetBox, bazı kalemlerde gerçeğin kaynağının başka bir sistem olamayacağında ısrar etmeyip merkezi bir depo olmayı hedefleseydi, hikâye farklı olabilirdi
Karmaşıklığı ve kontrolü merkezileştirme girişiminin çalışmadığını öğrendik. Clinger-Cohen Act geçtikten hemen sonra bile bunu neredeyse hemen anlamıştık; artık ITIL ve TOGAF da bunu açıkça ele alıyor. Önümüzdeki birkaç yıl boyunca danışmanların bu noktaya çok yükleneceğini düşünüyorum
Durumu bulmak için merkezi ve tutarlı bir yönteme ihtiyaç var. Yetkili bilginin nerede bulunacağına dair şüpheyi ortadan kaldırmak için
Ama ölçeklenmek, büyümek veya yeni değişimlere uyum sağlamak istiyorsanız, bu tür merkezi tanrı kutusu gibi normatif sistemlerden kaçınmak gerekir
Kullanması çok tatmin veren bir yazılım değil
Bu, yaygın “X’e ihtiyacımız var ve Y, X’i yapıyor” örneği; ama Y’nin Z, M, Q’yu da yaptığı ve bulaşıkları bile yıkadığı gerçeğini, ayrıca bunlara ihtiyacınız olmadığını görmezden gelmek
Bazen yalnızca ihtiyaç duyduğunuz şeyi yapmak en kolay çözümdür. Özellikle ihtiyaç duyduğunuz şey bir veritabanının önündeki CRUD ise
Aslında sadece kapsamı genişletiyorsunuz. NetBox, oradan başlayıp sisteminizi onun etrafına uydurmaya razıysanız iyi bir başlangıç noktası
Ama zaten bir sisteminiz varsa veya NetBox mantığına uymayan şeyler yapmanız gerekiyorsa, mevcut sistemi genişletmek muhtemelen daha iyi olur
Bu durumda Railway’in raflar, IP adresleri ve fiziksel sunucuların çok ötesinde çok daha fazla ek bilgiyi dikkate alması gerekiyor
Büyük bir teknoloji şirketinde ekipman onarım otomasyonu üzerinde çalışmıştım. Onarımın hafife alındığını ama ele alınması en zor işlerden biri olduğunu düşünüyorum
AWS üzerinde çalışırken arızalı donanımla pek ilgilenmezsiniz. Genelde kendi kendine onarılır
Kendiniz işletiyorsanız böyle bir lüksünüz yok. Yedek parçalar, onarım yapacak teknisyenler, işleri host’tan çıkarıp geri alma prosedürleri, test suite’leri, donanım izleme araçları ve daha 1001 şey gerekir
Küçük ölçekte bunların bir kısmını idareten geçiştirebilirsiniz, ama sonunda canınızı yakar. Üstelik bu sadece sunucularla ilgili kısım
Ağ ekipmanının da ayrı bir eğlenceli sorunlar kümesi vardır ve arızalanırsa tüm rafı indirebilir. Tepe yük sırasında colocation sağlayıcınızın elektriği kaybetmeyeceğine ne kadar güvenebilirsiniz? Bu tür durumlara hazırlık için felaket kurtarma tatbikatları yapmanızı umarım
Bu ekibe bol şans. Eğlenceli görünüyor
Kariyerimde yaşadığım bazı günleri hatırlattı. 2003–2010 arasında on binlerce sunucu dağıtmamız gerekti ve veri merkezleri hakkında oldukça ilginç şeyler öğrendim
Kablo yönetimi ve standardizasyon son derece önemliydi. Dağınık pratiklerle ayakta kalamazdınız
Her hafta yüzlerce sunucu dağıttığımız yerde, bir sunucu ana kümelerden birinden farklı olduğunda operatörün seçebileceği bir menü vardı. Temelde iki kasa vardı: 2U yüksek kapasiteli disk sunucusu veya 1U pizza kutusu. Diskler 9/36/146 GB SCSI arasından seçilebiliyordu
Hepsi aynı işlemcinin çift işlemcili yapılandırmasıydı; rafın altına yaklaşık 10 adet 2U kutu, geri kalanına da 20’den fazla 1U kutu yerleştiriyorduk
Yanlış hatırlamıyorsam elektrik fiyatını çok iyi koşullarla almıştık; muhtemelen kafes içinde tesisin raflarını kullandığımız içindi. O rafları kullanınca ilk iki adet 30A 240V devreyi ücretsiz veriyor gibilerdi
10 yıllık sözleşmeydi ve ölçüm de yoktu, bu yüzden her rafı olabildiğince sıkı doldurduk. Bir tarafa iki adet 30A, diğer tarafa iki adet 20A koyduk
Dışarı verdiğimiz ısıyı ve güç tüketimini düşününce veri merkezi neredeyse başa baş noktasında çalışmış olmalı. Belki de bağlantı veya peering ücretleriyle telafi ediyorlardı
Ayrıntıları pek hatırlamıyorum; o dönem orada çalışan arkadaşıma doğrulatmam lazım
Bulutta olması doğru olan yerler var, olmayan yerler de var. En iyi örnek yüksek bant genişliği veya diski yoğun kullanan uygulamalar
Netflix’e bakarsanız neredeyse her şey bulutta, ama gerçek video iletimini kendi donanımıyla yapıyor. Netflix ölçeğinde bile bunu başkasına ücret ödeyerek yapsalardı ekonomik olarak mümkün olur muydu, emin değilim
Sık gördüğüm rakamları biraz değiştirirsek: 20 PB çıkış trafiği, GB başına 0,02 dolar olursa ayda 400 bin dolar eder
20 PB, kabaca 95. persentil bazında 67 Gbps’ye karşılık gelir
100 Gbps sabit ücretli hattı ayda 5 bin dolara bulmak zor değil
Elbette bu aşırı basitleştirilmiş bir hesap ve gerçekte çok daha fazla unsur var. Yine de fark büyük
Bazı şirketler için yılda 4,68 milyon dolar önemli olmayabilir; başka şirketler içinse hayatta kalma meselesi olabilir
Çok daha fazla ayrıntı olmasını isterdim. WTF bölümü en iyisiydi
Ekipmanlarda “bu tarafı düşmana doğru çevirin” gibi etiketlere ya da yalnızca tek yönde takılmasını sağlayan uygun affordance’lara ihtiyaç var gibi görünüyor
Raf düzeyinde yerleşimi standartlaştırdınız mı? Hataları önlemek için hangi poka-yoke prosedürlerini koydunuz?
Bare metal’den boot’a kadar stack nasıl görünüyor?
İki farklı bulut sağlayıcısında çalışmış ve PXE boot host’larıyla kendi iç bulutunu kurmuş biri olarak bu tür içerikler gerçekten ilginç
Yeni bir veri merkezini başlatırken bundan olabildiğince yararlanıp akla gelen tüm hata senaryolarını, ayrıca rastgele arıza enjeksiyonuyla akla gelmeyen senaryoları da test etmek iyi olur
Raf düzeyi yerleşim standardizasyonunu şimdi yapıyoruz. Bunu ancak ikinci sahadan sonra fark ettik. Bu sayede doğrulama çok daha kolaylaştı
Doğrulama zor ve şu ana kadar manuel yapıyoruz. LLDP verilerini toplamayı denemek istiyorum ama switch yazılım stack’inde bug var
Sürekli evrilen bir süreç. Farklı yüklenicilerle çalıştıkça daha fazla uç durum keşfedip bunları sürece dahil ediyoruz
En büyük iyileştirme, raf tasarımını şablonlaştıran ve saha teknisyenlerine interaktif bir “kablolama gezgini” çıktısı veren dahili bir DCIM oluşturmamız oldu. Port adları vb. gösterilen ekipmanların ayrıntılı açıklamalı diyagramları da buna dahil. Yazıdaki raf görünüşü ekran görüntüsü de bu aracın bir parçası
Bare metal’den boot’a kadar olan kısım için https://github.com/danderson/netboot/tree/main/pixiecore üzerine hack’leyerek yaptığımız bir şey var. Debian netboot ve preseed dosyası sunuyor
BMC’nin Redfish API’sine bağlanıp bu cihazı yöneten özel bir Temporal worker’ımız da var. Ardından özel bir host agent QEMU VM’lerini provision ediyor ve host üzerinde FRR kullanarak tahsis edilen IP’yi BGP ile duyuruyor
Yeni veri merkezi hata senaryoları konusunda, şalterleri attırarak test yaptık ve bu sayede faz dengelemesinin bozuk olduğunu fark ettik. Başka bir sahada termal kamerayla içeri girdik
Önümüzdeki hafta AMS sahası devreye giriyor; hedef, tamamen doldurulmuş bir switch fabric’i ne kadar zorlayabileceğimizi görmek
Güzel yazı. 100G hız gerektiğinde Google gerçekten fena fiyat çıkarıyor. Neredeyse hakaret gibi
Örneğin yedekli 100G Dedicated Interconnect aylık yaklaşık 35 bin dolar ve buna VLAN attachment, colocation cross-connect maliyeti, transit vb. dahil değil. Üstelik VLAN attachment en fazla 50G
Bu maliyeti karşılaştırırsak, aynı paraya Arista’nın yeni 32 portlu 100G switch’lerinden 2 adet satın alabilirsiniz
Kuzey Amerika’da 100G WAN devresi, yani yönetilen Wavelength, aylık 5 bin doların altında bulunabiliyor. Yerel metroda ise dark fiber’ı daha ucuza alıp istediğiniz hızda çalıştırmak da mümkün