PB düzeyinde veri taşıma sistemi
Yazar Zhang Dongmao
PB düzeyinde nesne depolama veri taşıma platformu
1
Optimus talep analizi
Optimus, PB düzeyinde bir nesne depolama veri taşıma platformudur.Piyasadaki yaygın veri taşıma senaryolarından doğmuştur ve tipik müşteri, tüm ağa dayalı ve depolama platformlarından bağımsız olarak kendi geliştirdiği bir dizi veri taşıma platformu oluşturma gereksinimlerinden doğmuştur. Geleneksel geçiş sisteminden farklıdır, istemci kurulumu ve yardımcı harici ekipman gerektirmez ve otomatik veri geçişini gerçekleştirmek için tümü ağa dayanır.
1.1. Orijinal gereksinimler
Ø Kullanıcılar ticari nesne depolaması satın aldıktan veya kendi nesne depolama sistemlerini (ceph, minio ve openstack swift gibi açık kaynaklara dayalı olarak) oluşturduktan sonra, verileri orijinal depolama platformundan yeni dağıtılmış depolama platformuna hızlı ve istikrarlı bir şekilde taşımaları gerekir. Veri ölçeği genellikle Birkaç yüz TB'den fazla
Ø Kullanıcının orijinal nesne depolama platformu, erişim bağlantılarının sayısını sınırlandıran sınırlı performansa sahiptir. Diğer platformların kaynağa geri çağırması veya CDN yapması için harici bir erişim kaynağı olarak yeni bir platform gereklidir. Aynı zamanda, yeni oluşturulan dosyalara erişilebildiğinden emin olmak gerekir.
Ø Kullanıcının orijinal nesne depolama platformunun bant genişliği sınırlıdır ve içerik üretim platformunun, içerik üretim döneminde ve içerik meşgul olduğunda işletmenin normal erişimini karşılaması gerekir ve veri geçişi boştayken çekilebilir ve taşınabilir.
1.2. Geleneksel çözüm
Uygulamada, tek başına veri yönetimi araçları (s3cmd, cyberduck, vb.) Genellikle geçişi uygulamak için kullanılır. Karşılaşılan en büyük sorun, özellikle aynı anda indirirken ve karşıya yüklerken, tek başına bant genişliği darboğazıdır, daha fazla bant genişliği gerekir.
Bant genişliği sorunlarına ek olarak, tek bir makinede büyük miktarda veriyi taşırken aşağıdaki sorunlar da vardır:
Ø Yüksek kullanılabilirlik elde edilemez, dosya yükleme otomatik olarak yeniden denenemez
Ø Veri bütünlüğü garanti edilemez
Ø Eski depolama platformundaki veriler artmaya devam ederse, artımlı geçiş sağlanamaz ve manuel müdahale gerekir
1.3. Talep analizi ve iş süreci
1.3.1. Talep analizi
Yukarıdaki analize dayanarak, dağıtılmış, elastik olarak daraltılabilir ve yüksek düzeyde kullanılabilir bir veri taşıma platformunun büyük ölçekli veri depolama geçiş ihtiyaçlarına yanıt verebileceği görülebilir.
Ø Dağıtılmış
Veri taşıma bant genişliğini büyük ölçüde artırabilen birden çok sunucu sağlayın
Ø Elastik daralma
Uygulamada, veri taşıma hizmetine çoğu zaman erişilmediğini, ancak büyük görevler olduğunda, daha ağır IO (yükleme ve indirme) ve CPU (veri bütünlüğünü doğrulamak için MD5 hesaplama) haline geldiğini gördük.
Ø Yüksek kullanılabilirlik
Veri geçişinin bütünlüğü için, tek bir dosyanın bütünlüğünü doğrulamaya ek olarak, tüm dosyaların başarılı bir şekilde geçirilip geçirilmediğini ve herhangi bir eksikliğin olmadığını doğrulamak gerekir.Sistem düzeyinde bir yeniden deneme mekanizmasının sağlanması gerekir.
Ek olarak, platformun şunlara da sahip olması gerekir:
Ø Yetki kimlik doğrulaması: kullanıcıların kimliğini doğrulama, yasal erişim
Ø Açık Restful arayüzü: ikincil geliştirme için kullanıcı entegrasyonunu kolaylaştırmak için açık bir arayüz sağlar
Ø Dizin yapısı tutarlılığı garantisi: Geçişten önceki ve sonraki dosyaların dizin yapısının değişmediğinden ve geçişten sonra normal erişimi etkilemediğinden emin olun
1.3.2. İş Süreci
Basitleştirilmiş geçiş süreci şekilde gösterilmektedir:
1) Kullanıcı, kimlik doğrulama modülü aracılığıyla veri taşıma platformunun iznini doğrular (AK / SK veya kullanıcı adı / parola ve depolama alanının anahtarı ile doğrulanır)
2) Doğrulama geçtikten sonra, kullanıcı konsolu veya belirlenmiş API'yi kullanarak geçiş içeriği yolunu geçiş dağıtım modülüne iletebilir (adresler toplu olarak gönderilebilir)
3) Taşıma dağıtım modülü kaynak dosyaları yola göre çeker
4) Çekilmiş dosyayı hedef depolama platformunda depolayın (içeriğin kaynak depolama dizini yapısına göre depolanması gerekir)
5) Veri taşıma platformu, kullanıcı geçiş sonuçlarını döndürür
2
Optimus Active Migration System 2.1. İşlev Tanıtımı
İçeriğin bu kısmının anlaşılması çok kolaydır, taşıma senaryosunun aşağıdaki gibi olduğu varsayılır:
Http://domain.com web sitesi altındaki üç dosyayı, yani abc.txt, def.jpg, bad.mp4 bir S3 hizmetine taşıyın ve karşılık gelen paket adı bucketone'dur.
Bu nedenle, kayıtlı bir kullanıcı, kimlik doğrulama başarılı olursa hizmete bir PUT isteği başlatabilir.
İstek gövdesi aşağıdaki gibidir:
{
"kaynak dosyalar" :,
"target-type": "s3",
"target-kova": "bucketone",
"target-acl": "genel okuma",
}
Sunucu 200 döndürürse, bu, geçiş platformunun görevi kabul ettiği ve kaynak durumuna veya belirtilen zamana göre geçiş görevini yürütmeye başlayacağı anlamına gelir.
Kullanıcılar, geri arama URL'si veya durum API'si aracılığıyla görev ilerlemesini görüntüleyebilir veya aşağıdaki görsel konsoldan ilerlemeyi görüntüleyebilir.
Şekilde JobID'yi genişletin, belirli geçiş dosyalarını ve dosya geçişinin ilerlemesini ve durumunu görüntüleyebilirsiniz.
2.2. Uygulama planı
İşlevin bu kısmı sezgisel olarak çok basit, sadece geçiş görevini birkaç sunucuya atamak değil mi? Görevi kabul eden, görevi bölen ve ardından görevi bir ajan sunucusuna atayan bir ana sunucu olduğu sürece.
Ancak yine de bazı zorluklar var:
1. Aracıda nasıl veri toplanır ve geçiş görevlerini çalıştırmak için kaynak olup olmadığı kontrol edilir
2. Geçiş görevlerini izole edin ve birbirinizi etkilemeyin
Dikkatlice düşünün, bu tipik bir kaynak planlama problemi değil mi? Tekerlekleri yeniden icat etmeye gerek yok, birçok opsiyonel çerçeve var
Ø kubernetes
Ø Mesos
Ø Google Borg
Bu kaynakları yönetebilirsiniz, hızlı gelişim için en iyi Mesos'u seçtik.
Mesos ilkesi ve mimarisi:
1. Mesos Agent1, aslında, belirli bir çalışanın Mesos ana birimine kaç tane kaynak bildirdiğidir. Burada 4CPU ve 4GB bellek bildirir
2. Mesos yöneticisi, her Çerçeveyi sorgular ve 4CPU ve 4GB bellek kaynakları olduğunu bildirir
3. Çerçeve1, Mesos yöneticisi tarafından soruldu. Artık kümede 4CPU ve 4GB bellek var Görevler için bu kaynaklara ihtiyacınız var mı? Sözde Çerçeve aslında Mesos yöneticisine kayıtlı bir arka plan programıdır. En önemli görevi bir resourceOffer işlevi uygulamaktır:
ResourceOffers (sürücü sched.SchedulerDriver, * Mesos.Offer sunar)
Mesos.Offer'ın içinde "4CPU ve 4GB'im var" bilgisi bulunur. Şu anda, Framework1'in ResourceOffer'ı, 4CPU ve 4GB kaynak ile çalıştırılabilecek bir görev olup olmadığını görmek için çalıştırmak istediği işi kontrol eder. , Görev1 gibi 2 Görev oluşturulur, ana bilgiler şunları içerir:
Ø 2CPU ve 1GB hafızayı kaplar
Ø görev kimliği numarası
Ø Görevi çalıştıran programın http indirme adresi
4. Mesos yöneticisi, Framework1'den Görev bilgilerini alır, Mesos Agent1'deki kaynakları tahsis eder, yürütülebilir kodu indirir ve Task'ı çalıştırır
2.3. Sistem mimarisini taşıma
Optimus, Mesos Framework'ün bir uygulamasıdır.Maraton ve aurora gibi ünlü Framework'ler gibi bir Mesos zamanlayıcıdır ve Mesos platformunda çalışır.
Yukarıdaki Mesos prensibine göre, bir görev platformu oluşturmak kolaydır, süreç aşağıdaki gibidir:
1. Mesos master, Optimus Framework'ten bir kaynak teklifi yapmasını ve atanacak görevler olup olmadığını sorar.
2. Teklif talebini aldıktan sonra Optimus Framework, taşıma işi ve Mesos tarafından sağlanan kaynakları eşleştirmek için veritabanını sorgular.Uygun kaynaklar varsa, bir işi böler (örneğin, taşınacak 1W dosyalar gibi iş çok büyük olabilir). Birkaç küçük göreve bölün ve Mesos ustasına geri dönün
3. Optimus Framework bölünmüş görevleri döndürür
4. Mesos master, aracılara kendi mantığına göre görevler atar
5. Aracı üzerinde görevleri çalıştırın ve kolay sorgulama için geçiş sonuçlarını ve ara durumu veritabanına kaydedin
2.4 Optimus beklenen sonuçları elde ediyor mu?
Ø Dağıtılmış
Bu, Mesos'un kaç aracıya bağlanabileceğine bağlıdır .. Yayınlanan makalelerden, Mesos, üretim ortamındaki binlerce düğümü birbirine bağlar ve bu, doğrusal olarak kolayca genişletilebilir. Optimus Framework tek bir nokta olmasına rağmen, tüm hesaplamalar tek bir sunucu üzerinde yoğunlaşmıştır, ancak görevlerin bölünmesinin CPU baskısının çok küçük olduğu düşünüldüğünde göz ardı edilebilir.
Ø Elastik daralma
Mesos kümesinin kaynaklarının yetersiz olduğunu fark ederseniz, Mesos kümesine bir sunucu eklemek çok basittir.Mesos ajanı konuşlandırıldığı sürece tüm programları sandbox altında çalışır ve işlem tamamlandıktan sonra otomatik olarak temizlenir. Optimus Framework olmadan veya taşıma görevleri olmadan, Mesos kümesi maraton gibi diğer hesaplamalar için çerçevelere bağlanabilir. Bu şekilde, bu geçiş platformu tamamen ölçeklenebilir.
Ø Yüksek kullanılabilirlik
Bu soru 2 bölüme ayrılmıştır:
1) Mesos platformunun yüksek kullanılabilirliği
En önemlilerinden biri, Mesos master'ın yüksek kullanılabilirliği, bu makaleye Mesos High Availability ( başvurabilirsiniz.
2) Optimus platformunun yüksek kullanılabilirliği
MySQL burada veri bütünlüğünü sağlamak için bir ana yedekleme mimarisi kullanır. Optimus Framework gerçekten bağımsızdır. Ancak bu tamamen durumsuz bir programdır çünkü kayıtlı durum Mesos'ta saklanır ve iş durumu veritabanında saklanır. Optimus Framework'ü kolayca maratona veya kubernetes'e veya daha geleneksel kalp piline yerleştirebilirsiniz.
2.5. Optimus'un uygulamadaki deneyimi
2.5.1. Tüm Mesos mesajları güvenilir değildir
Mesos Kılavuz Kitabına bakın (
Mesos, varsayılan olarak bileşenler arasında güvenilmez mesajlaşma sağlar
Mesos sisteminin yeniden göndermenize yardımcı olacağı durum güncelleme mesajı dışında diğer tüm mesajlar güvenilir değildir. Bu, Framework geliştiricilerinin Görevin durumunu kendilerinin depolamasını gerektirir.Örneğin, verileri MySQL'de saklıyoruz ve görevin yeniden planlanması gerekip gerekmediğini belirlemek için zaman aşımını kendimiz yapıyoruz.
Ek olarak, Kılavuz kitapta, çerçevenin kendisinin seçimle yüksek oranda erişilebilir hale getirilebileceğinden de bahsediliyor, ancak bu kodlama çok daha karmaşık olacak (bellek verilerini senkronize etme ve liderin gerçekten çalışmadığını kontrol etme ihtiyacı nedeniyle), en basit yolu uyguladık: Tüm veriler MySQL'de saklanır ve ardından Optimus Framework'ü maratona sokar
2.5.2. Optimus Framework ve Mesos Executor'u geliştirmek için neden Golang kullanılıyor?
İlki, Mesos Executor'u tanıtmaktır. Executor, Mesos aracısının sandbox'ta çalıştırdığı bir programdır. Örneğin, bu Executor'un Optimus'taki yürütme mantığı
url = GetUrl ()
temp_file = http.get (url)
s3.upload (temp_file);
Bu kadar basit. C ++, Java, Python, Golang, Scala desteklenmektedir. Basit kodlamaya ek olarak, Golang çok büyük bir avantaja sahiptir.Kurulumu ve yükseltmesi özellikle kolaydır.Tüm bağımlılıklar statik olarak derlenir.Bir ikili derlendiği sürece çalışabilir. Python'da yazılan önceki yürütücünün aksine, yalnızca bota güvenmekle kalmaz, aynı zamanda bağımlılıkları indirmek için bir preinstall.sh betiği çalıştırması gerekir.
çok sıkıntılı! ! !
Buna ek olarak, çevrimiçi aracılar arasında CentOS6 ve CentOS7 ve hatta bir Ubuntu bulunur.Statik olarak derlenmiş Golang ikili dosyası, üzerinde kararlı bir şekilde çalışır.
Elbette, bazı insanlar Mesos'un konteynerleri de desteklediğini sorabilir, neden Docker kullanılmasın?
Cevap: Sonuçta, Golang ikili dosyasını derlemek Docker görüntüsünden çok daha küçüktür
Executor Golang'da yazıldığından beri, projenin tutarlılığı için Optimus Framework Golang'da da uygulanıyor. Daha önce hala bazı sorularımız var. Sonuçta, resmi Mesos örneklerinin çoğu Java ve Python. Kütüphane Golang kararlı mı çalışıyor? Mesos topluluğunun hala Golang versiyonunu deneysel bir versiyon olarak kullanmasına rağmen, çevrimiçi çalışmamızın sonuçlarının çok kararlı olduğunu kanıtlıyor.
2.6. Pratikte Optimus'un tipik uygulaması
Ø Tam uzaktan yedekleme
Kullanıcı, tam veri URL listesini Optimus kümesine gönderir.Her iş tamamlandıktan sonra, otomatik olarak işin tamamlanmasını ister.İşte bir hata varsa, otomatik olarak yeniden dener.
Ø Artımlı uzaktan yedekleme
Biz de böyle bir durumla karşılaştık.Amerikalı kullanıcılar Amazon S3'ü film kaynaklarını depolamak için bir hizmet olarak kullanıyor, yeni filmler varsa başka bir yerde yedeklenmesi gerekiyor. Bu yapı, bu gereksinim için benimsenmiştir
Amazon S3 verileri depolar. Yeni bir dosya eklendiğinde, Amazon sqs'de yeni bir mesaj görünür. Bu mesaj Optimus'a http biçiminde gönderilirse, yalnızca bu artımlı video taşınacaktır.
3
Optimus kaynak sisteme otomatik dönüş 3.1. İşlev tanıtımı
Yukarıdaki sistemde, URL listesini düzenlemek ve URL'yi göndermek için bir program yazmak yine de gereklidir. Bazı kullanıcılar bunu çok zahmetli buluyor ve tembel bir yol olup olmadığını araştırıyor. S3 depolamasının kaçırılması durumunda, verileri almak ve kullanıcıya iade etmek için kaynak siteyi ziyaret edin.
Bu işlev şekilde gösterildiği gibidir, turuncu kaynak istasyonu belirtir ve bir ara katman vardır. Http kodunu kontrol ederken dönüş değeri. 404 ise, bu ara katmanın iki şey yapması gerekir:
1. Yapılandırılan kaynak siteden verileri alın ve bu isteğin sorunsuz bir şekilde tamamlanmasını sağlamak için kullanıcıya geri gönderin
2. Aşağı çekilen geçici dosyaları tekrar depoya yükleyin ve daha sonra istenirse aynı dosyaların kaynak siteye geri gönderilmemesini sağlamak için bunları otomatik olarak yansıtın
Bu sistemin avantajları çok açık:
1. OnDemand'ın indirme isteği, büyük ölçekli bir geçişin baskısını büyük ölçüde azaltır
2. Kaynak istasyonun yalnızca gruba karşılık gelen kaynağa dönüş adresini herhangi bir kod yazmadan yapılandırması gerekir
3. Yapılandırma tamamlandıktan sonra, yeni depolama birimi, kaynak site içeriğini otomatik ve sorunsuz bir şekilde yansıtabilir
3.2. Uygulama planı
3.2.1. Birinci Seçenek
1. S3 API'nin bütünlüğünü sağlamak için S3 standart API'yi değiştirmeye gerek yoktur, yalnızca proxy katmanını değiştirmeye gerek yoktur. 7 katmanlı proxy burada Openresty'yi seçer. Openresty, Nginx modüllerini çağırmak için Lua'yı kolayca kullanabilir.
2. Openresty katmanında, dönüş değerini kontrol etmek için Lua kodunu kullanın 404 ise, veritabanı kullanıcısı tarafından istenen Movie / a.mp4 dosyasının kaynak adresine otomatik dönüş ile yapılandırılıp yapılandırılmadığını sorgulayın. Veritabanını sorgulayarak, Film grubuna karşılık gelen başlangıç noktasına dönüş adresinin olduğu bulundu. URL'yi kadar kullanıcı ile kararlaştırılan kurallara göre yeniden yazın
3. Lua betiği yeni bir eşdizimler başlatır, geçici adrese bir http GET indirmesi başlatır ve indirme tamamlandıktan sonra onu S3 depolamasına yükler. Öte yandan, Openresty, indirilen geçici dosyayı kullanıcıya, kullanıcıya şeffaf olarak gönderir.Kullanıcının, indirmeden önce dosyanın S3 depolamasında bulunması gerektiğini bilmesine gerek yoktur.
4. Pratikte başka bir seçenek daha var: İndirirken 404 olduğu tespit edilirse, kullanıcıya 302 verebilir ve kullanıcının kaynak siteye geri dönmesine izin verebilirsiniz, ardından Openresty kaynak dosyayı eşzamansız olarak indirecektir. Ancak bunun bir dezavantajı var. Kullanıcının çok sayıda dosyası varsa veya birden fazla kullanıcı aynı dosyayı indirirse, tüm atlamalar kullanıcının başlangıç sitesine daha fazla kısa vadeli baskı getirecek ve bu da bulut depolama aynalamanın anlamını yitirecektir. Bu nedenle, S3 sunucusuna baskı yapmayı seçin ve bir strateji ekleyin, kullanıcılar kaynak istasyonları için maksimum indirme bant genişliğini yapılandırabilir.
3.2.2. Şema İki
1. seçenekte üstesinden gelinmesi gereken iki eksiklik vardır:
Ø Bu sistem hala biraz ağır. Paket ile orijin arasındaki eşlemeyi depolamak için bir veritabanı eklemek çok israftır. Veri tablosunun on milyonlarca satırı geçmeyeceği tahmin edilebilir.
Ø Depolamada bulunmayan aynı dosyayı aynı anda birden fazla kullanıcı indirdiğinde, bu isteklerin hepsinin aynı Openresty'ye düşeceğini umuyoruz.
Yani özetle. İhtiyacımız olan yeni işlevler şunlardır:
1. Paket ve kaynak site adresi arasındaki eşlemeyi depolamak için mevcut Openresty sunucusunu yeniden kullanan yeterince hafif dağıtılmış bir KV veritabanı.
2. Bir yönlendirici algoritması, tüm kaynağa dönüş isteklerinin aynı Openresty'ye düşmesini garanti eder.Buradaki en basit algoritma, URL'de md5sum yapmak ve ardından modu getirmektir.
SelectedNode = md5sum ("Film / a.mp4")% cluster.length
Yüksek kullanılabilirlik elde etmek için, sistemin Openresty düğümünün kullanılabilir olup olmadığını otomatik olarak kontrol edebilmesi ve üye listesinin yönetilmesi gerekiyor.
Yukarıdaki iki gerekliliğe dayanarak, basit bir seçim yapmak için burada iyi bilinen ve biraz önyargılı açık kaynak uygulamaları seçmedik. Bunun yerine, kütüphane dosyasını seçtim ve en hafif ve en küçük sistemi elde etmek için üzerinde ikincil geliştirme yaptım.
1. Dağıtılmış kv: Raft, tanınmış Etcd de benzer bir algoritma kullanıyor, temel depolama olarak boltdb kullanıyoruz
2. İki ana akım kalp atışı algoritması vardır: Biri, hdfs gibi ana düğüm tarafından bildirilen algoritmadır ve bazıları cassandra gibi dedikodu algoritmasını kullanır. Burada bir açık kaynak dedikodu kütüphanesi üye listesi seçtik. Konsolosluğa çok benzer
Açık kaynaklı bir uygulama yerine açık kaynaklı bir kitaplık seçmemizin nedeni, operasyon ve bakım için çok sayıda dağıtım belgesi yazan bir uygulama değil, çok hafif ve dağıtımı kolay bir ikili program oluşturmak istememizdir.
Mimari diyagram aşağıdaki gibidir:
1. Önceki şema 1'deki MySQL, sal protokolü altında çalışan boltdb ile değiştirildi
2. Openresty artık gevşek bir ilişki değildir, üye listesini korumak için dedikodu protokolüne güvenebilirler, böylece Openresty'nin sunucusu kapalı veya tekrar çevrimiçi olursa olsun, otomatik olarak keşfedilebilir ve otomatik olarak kaldırılabilir.
3.3. Pratikte kaynağa otomatik dönüşün tipik uygulaması
1. Tam uzaktan yedekleme
Kullanıcıların yalnızca yedeklemeleri gereken verilerin URL listesini almaları ve her URL için bir HEAD isteği başlatmaları gerekir. Bunun bir GET isteği olmadığını unutmayın. Bir GET isteği ise indirilecektir.
2. Artımlı uzaktan yedekleme
Otomatik kaynağa dönüş sistemi, kaynak istasyonun kullanıcı için tamamen şeffaf olan ayna görüntüsüne eşdeğerdir. Paket ile kaynak istasyon arasındaki eşleştirme ilişkisi yapılandırıldığı sürece, kullanıcı S3 depolamasını (otomatik senkronizasyon) tıpkı kendi kaynak istasyonu gibi (tüm verilerle) kullanabilir Gerekli veriler)
Yazar hakkında:
Zhang Dongmao HNA Cloud Yijian Technology Cloud Service Business Group Altyapı Merkezi Müdürü.Linux işletim sistemi ve dağıtılmış sistem geliştirme konusunda yaklaşık 10 yıllık deneyime sahip.Ana araştırma alanları açık kaynaklı yazılımlar, dağıtılmış depolama sistemleri ve veritabanı sistemleridir. 2014'ten önce, Linux işletim sisteminin geliştirilmesine odaklandı ve hem LVM hem de Linux Kümesine kod katkısında bulundu. 2014'te Ceph topluluğuna katılmaya başladı ve depolama ekibi Ceph topluluğu katkılarının ön saflarında yer alıyor.
Bulut teknolojisi topluluğu tanıtımı:
Bulut teknolojisi topluluğu 2014 yılında kurulmuştur. Çin'deki en büyük bulut teknolojisi değişim platformudur. Bulut bilişim / sanallaştırma projelerinin uygulanmasında bilgi, deneyim ve teknolojiyi paylaşır ve kuru mallarda ısrar eder.
