İlk obyekt saxlama prototipi 1996-cı ildə dünya tərəfindən görüldü. 10 ildən sonra Amazon Web Services Amazon S3-i işə saldı və dünya düz ünvan sahəsinin funksiyalarından istifadə etməyə başladığına görə ajiotaj yaratmağa başladı. Metadata ilə iş və yük altında zəifləmədən miqyaslana bilmək qabiliyyətinə görə obyekt saxlama sistemləri tez bir zamanda bulud məlumat saxlama xidmətləri üçün standart halına gəldi, yalnız bunda deyil. Digər mühüm bir xüsusiyyət - arxivlərin və nadir istifadə olunan faylların saxlanması üçün yaxşı uyğunluğudur. Məlumat saxlamayla məşğul olanlar yeni texnologiyanı bayram edərək mükafatlandırdılar.
Amma insanların arasında obyekt saxlama sistemlərinin yalnız böyük buludlar üçün olduğu haqqında şayiələr yayılırdı, əgər sizə lənətlənmiş kapitalistlərin həlləri lazım deyilsə, özünüzün edilməsi çox çətin olacaq. Öz buludunuzu yaratmaqla bağlı artıq çox şey yazılıb, S3-uyğun sistemlərin yaradılması ilə bağlı isə informasiya azdır.
Buna görə də bu gün "Böyüklərdəki kimi olsun, CEPH yox, daha çox işləmə alətləri ilə" olan variantları araşdıracağıq, bunlardan birini işə salacağıq, və onu Veeam Backup & Replication vasitəsilə yoxlayacağıq. Burada S3-uyğun saxlama ilə işləmə dəstəyi olduğu bildirilir və bu bəyanatı yoxlayacağıq.
Digər istifadəçilərin vəziyyəti necədir?
Kiçik bir bazar araşdırması və obyekt saxlama variantlarının nəzərdən keçirilməsi ilə başlamağı təklif edirəm. Ümumi qəbul edilmiş lider və standart - Amazon S3-dür. İki yaxın rəqib - Microsoft Azure Blob Storage və IBM Cloud Object Storage-dır.
Həqiqətən də, bu qədərmi? Başqa rəqiblər yoxdur? Əlbəttə, rəqiblər var, amma bəziləri Google Cloud və ya Oracle Cloud Object Storage kimi öz yolu ilə gedir, S3 API-tə tam dəstəyi yoxdur. Bəziləri köhnə API versiyalarından istifadə edir, məsələn, Baidu Cloud. Və bəziləri, Hitachi Cloud kimi, xüsusi məntiqin istifadəsini tələb edir ki, bu da öz çətinliklərini doğurur. Hər halda, hamı Amazon ilə müqayisə edilir, çünki bu, sənaye standartı hesab oluna bilər.
Ancaq on-premise həllərdə seçim daha çoxdur, buna görə də bizə əhəmiyyətli olan meyarları müəyyənləşdirək. Əslində, sadəcə iki şey kifayətdir: S3 API dəstəyi və v4 imza istifadə edilməsi. Ürəyimizi qoyaraq, gələcək müştəri olaraq, yalnız qarşılıqlı fəaliyyət üçün interfeys bizə maraqlıdır, saxlama sisteminin daxili mexanizmi isə artıq o qədər də maraqlı deyil.
Bu sadə tələblərə çoxsaylı həllər uyğundur. Məsələn, klassik korporativ ağırlıqlar:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade və StorReduce
- Huawei FusionStorage
Üçüncü tərəfin proqram təminatından istifadə edən həllər də var:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
Hətta montajdan sonra yaxşıca hazırlayanları da məyus etməyiblər:
- CEPH tam təmiz formada
- Minio (Linux versiyası, çünki Windows versiyası ilə bağlı çoxlu suallar var)
Siyah tamamilə yoxdur, bunu şərhlərdə müzakirə edə bilərik. Ancaq quraşdırmadan əvvəl API uyğunluğuna əlavə olaraq sistemin performansını da yoxlamağı unutmayın. Sizə lazım olan son şey — tıxanan sorğular səbəbindən terabaytlarla məlumat itkisi yaşamaqdır. Beləliklə, yükləmə testlərindən çəkinməyin. Əslində, böyük məlumat həcmləri ilə işləyən bütün yetkin proqramlar ən azı uyğunluq hesabatlarına malikdir. Veeam So, let's start the step-by-step implementation qarşılıqlı test üçün, məhsullarımızın konkret avadanlıqlarla tam uyğunluğunu iddia etməyə imkan tanıyır. Bu artıq iki tərəfli bir işdir, həmişə sürətli olmur, amma biz daim sınanmış həlləri genişləndiririk.
Stendimizi yığıb
təcrübə məsələsi ilə bağlı bir az danışmaq istəyirəm.
Birincisi, qutudan çıxanda dərhal işləyən bir variant tapmaq istədim. Yaxud da ən azı əlavə çaba sərf etmədən işləmə ehtimalının yüksək olduğu. Bütün o bulbullar və gecə boyunca konsolda qazmağı etmək olduqca maraqlıdır, amma bəzən işlərin dərhal görsənməsini istəyirəm. Ümumilikdə, belə həllərin etibarlılığı daha yüksək olur. Bəli, macəra ruhu itmişdir, pəncərələrdən sevdiyimiz qadınlara tırmanmırıq və s.
İkincisi, düzünü desək, obyekt depoları ilə işləmək tələbi olduqca böyük şirkətlərdə baş verir, buna görə də bu, enterprise səviyyəsi həllərinə yönəlmək üçün utanc verici deyil, əksinə təşviq olunur. Hər halda, mən hələ kimsəni belə həlləri əldə etdiyi üçün işdən çıxardıqları ilə bağlı misallar bilmirəm.
Yuxarıda qeyd olunanlardan çıxış edərək seçimin mənim üçün Dell EMC ECS Community Editionolduğunu düşündüm. Bu, çox maraqlı bir layihədir və bunu sizinlə paylaşmağı lazım bilirəm.
Göz qabağına gələn ilk şey Community Edition gördükdə, bunun hansısa məhdudiyyətləri olan tam ECS-nin tərkibi olduğunu düşünsəniz, bu, sadəcə bir lisenziya alaraq aradan qaldırılır. Amma belə deyil!
Yadda saxlayın:
!!!Community Edition — nəzərdə tutulan yalnız test üçün yaradılmış ayrı bir layihədir və Dell tərəfindən dəstək verilmir!!
Və istehsa bir tam ECS-yə çevrilmir, istəsəniz belə.
Gəlin məsələyə baxaq
Bir çoxları hesab edir ki, Dell EMC ECS — obyekt depolama ehtiyacı olanların ən yaxşı həllərindən biridir. ECS markası altında bütün layihələr, o cümlədən kommersiya və korporativ, bunun üzərinə daxildir. . Bu, Dell tərəfindən bir yaxşılıq jestidir. Və onların öz brend avadanlığında işləyən proqramlardan savayı, buludda, virtual maşında, konteynerdə və ya hər hansı öz avadanlığınızda qura biləcəyiniz açıq mənbə versiyası var. Araya girmək — hətta OVA versiyası var, onu da istifadə edəcəyik.
DELL ECS Community Edition — tam versiyanın mini bir variantıdır, Dell EMC ECS brend serverlərində işləyir.
Dörd əsas fərqi vurğuladım:
- Şifrələmə dəstəyi yoxdur. Üzücü, amma kritik deyil.
- Fabric Layer yoxdur. Bu, klasterlərin qurulması, resursların idarəsi, yeniləmələr, monitorinq və Docker şəkillərinin saxlanması ilə məşğuldur. Burada artıq çox üzgünəm, amma Dell'i də başa düşmək olar.
- Öncəki nöqtənin ən narahat edici nəticəsi: node boyutunu quraşdırma tamamlandıqdan sonra genişləndirmək mümkün deyil.
- Texniki dəstək yoxdur. Bu, kiçik quraşdırmalarda istənilən istifadə üçün icazə verilən bir test məhsuludur, amma şəxsən mən oraya petabaytlarla vacib məlumatlar yükləmək cəsarətini göstərməzdim. Amma texniki cəhətdən bunu etməyinizə heç kim mane ola bilməz.
Böyük versiyada nə var?
Avropanın küçələrində sürətlə irəliləyərək, texniki həllər haqqında daha ətraflı məlumat əldə etməyə çalışaq.
DELL ECS-nin ən yaxşı lokal obyekti depolama olduğunu təsdiqləmək və ya təkzib etmək istəmirəm, amma bu mövzuda fikriniz varsa, şərhlərdə məmnuniyyətlə oxuyaram. Hər hansı halda, Dell EMC, OBS bazarının beş liderindən biri olaraq sərt gəlir. Burada cloud-based həllər nəzərə alınmır, amma bu, ayrı bir söhbətdir.
Texniki cəhətdən ECS, bulud depolama protokolları vasitəsilə məlumatlara giriş təmin edən bir obyektdir. AWS S3 və OpenStack Swift dəstəkləyir. File-enabled tenkərlər üçün ECS, fayl səviyyəsində ixrac üçün NFSv3 dəstəyi var.
Məlumat yazma prosesi olduqca qeyri-adi, xüsusilə də klassik blok depolama sistemlərindən sonra.
- Yeni məlumat gəldikdə, adı, öz məlumatları və metadatası olan yeni bir obyektdir.
- Obyektlər 128 MB-lıq parçalara bölünür və hər bir parça dərhal üç nodetə yazılır.
- İndeks faylı yenilənir, burada identifikatorlar və saxlama yerləri qeydə alınır.
- Yazı jurnalının faylı (log) yenilənir və o da üç nodetə yazılır.
- Müştəriyə uğurlu yazma mesajı göndərilir.
Üç məlumat nüsxəsi paralel olaraq yazılır. Yazma yalnız bütün üç nüsxə uğurla yazıldıqda uğurlu sayılır.
Oxuma prosesi daha asandır:
- Müştəri məlumatları soruşur.
- İndeksdə məlumatların saxlandığı yer axtarılır.
- Məlumat bir nodetən oxunur və müştəriyə göndərilir.
Serverlərin sayı olduqca çoxdur, buna görə də ən kiçik Dell EMC ECS EX300-ə nəzər salaq. O, 60TB-dan başlayır və 1,5PB-ə qədər artırma imkanı var. Onun daha böyük qardaşı Dell EMC ECS EX3000 isə artıq bir rəfdə 8,6PB saxlamağa imkan tanıyır.
Yerləşdirmə
Texniki cəhətdən Dell ECS CE-ni istədiyiniz qədər böyütmək mümkündür. Hər halda, açıq şəkildə məhdudiyyətlər tapmadım. Ancaq bütün genişlənməni ilk nodu klonlamaqla rahatlıqla etmək olar, bunun üçün:
- 8 vCPU
- 64GB RAM
- 16GB əməliyyat sistemi üçün
- 1TB birbaşa saxlama üçün
- Son versiya CentOS minimal
Bu, hər şeyi başdan qurmaq istədiyiniz zaman üçün bir seçimdir. Bizim üçün bu seçim aktual deyil, çünki OVA görüntüsünü yaymaq üçün istifadə edəcəyəm.
Amma hər halda, tələblər bir nodedə belə çox çətindir, və əgər qanunun hərflərinə ciddi riayət etsək, belə nodlar dörd olmalıdır.
Ancaq ECS CE-nin inkişaf etdiriciləri real dünyada yaşayır və quraşdırma bir nod ilə də uğurla həyata keçirilir, minimum tələblər belədir:
- 4 vCPU
- 16 GB RAM
- İşlətmə sistemi üçün 16 GB
- 104 GB öz saxlama
OVA görüntüsünü yaymaq üçün belə resurslar tələb olunur. Artıq daha real və humanistdir.
Quraşdırma nodunu rəsmi saytdan ala bilərsiniz . Orada tam həcmdə yayma ilə bağlı ətraflı sənəd də var, amma rəsmi saytında daha oxuya bilərsiniz . Beləliklə, OVA-nın yayılması haqqında ətraflı dayanmaq istəmirik, orada heç bir fənd yoxdur. Əsas — başlatmadan əvvəl ya diski lazım olan həcmdə genişləndirin, ya da lazımi diskləri bağlayın.
Maşını başlatmaq, konsolu açmaq və ən yaxşı varsayılan kredentialları istifadə edirik:
- logaın: admin
- şifrə: ChangeMe
Sonra sudo nmtui işlədib şəbəkə interfeysini konfiqurasiya edirik — IP/mask, DNS və qapı. CentOS minimalda net-tools olmadığını nəzərə alaraq, parametrləri ip addr ilə yoxlayırıq.
Və yalnız cəsarətlilərə dənizlər fəth olunur, yum update edirik, daha sonra reboot. Əslində bu olduqca təhlükəsizdir, çünki bütün yayım playbook-lar vasitəsilə həyata keçirilir və Dockerın bütün vacib paketləri hazırkı versiyada kilidlidir.
İndi quraşdırma skriptini redaktə etmək üçün vaxt gəlib. Gözəl pəncərələr və ya pseudo UI yoxdur — hamısı sevdiyiniz mətn redaktorunuzla. Texniki cəhətdən iki yol var: ya hər əmri əl ilə işə sala bilərsiniz, ya da videploy konfiquratorunu dərhal işə sala bilərsiniz. O, yalnız konfiqurasiyanı vim-də açacaq və çıxanda onun yoxlanmasını başladaq. Amma həyatı bu qədər sadələşdirmək maraqlı deyil, ona görə iki əmr daha icra edəcəyik. Bunun heç bir mənası olmasa da, sizi xəbərdar etdim =)
Beləliklə, vim ECS-CommunityEdition/deploy.xml edir və ECS'nin işə düşməsi və işləməsi üçün optimal minimum dəyişikliklər edirik. Parametrlərin siyahısını qısa saxlamaq olar, amma mən belə etdim:
- licensed_accepted: true Bunu dəyişməyə də ehtiyac yoxdur, onda yayım zamanı onu qəbul etməyinizi açıq şəkildə xahiş edəcəklər və sizə gözəl bir ifadə göstərəcəklər. Bəlkə bu, hətta bir pasxaldır.
- autonames: və custom: sətirlərin şərhini açın. Nodedə ən azı bir istənilən ad daxil edin — hostname quraşdırma prosesi zamanı onunla əvəz olunacaq.
- install_node: 192.168.1.1 Real nodun IP-sini göstərin. Bizim halımızda nmtui-də göstərdiyimiz ilə eyni göstəririk.
- dns_domain: öz domenimizi daxil edirik.
- dns_servers: öz dns-imizi yazırıq.
- ntp_servers: hər hansı birini göstərə bilərsiniz. Mən 0.pool.ntp.org-dan ilk tapdığımını götürdüm (91.216.168.42 oldu)
- autonaming: custom Şərhini açmasanız, ay Luna adlanacaq.
- ecs_block_devices:
/dev/sdb
Nedensiz bir şekilde burada mevcut olmayan bir blok depolama cihazı /dev/vda olabilir. - depo havuzları:
üyeler:
192.168.1.1 Burada tekrar gerçek düğüm IP'sini belirtiyoruz. - ecs_block_devices:
/dev/sdb Повторяем операцию вырезания несуществующих устройств.
Aslında tüm dosya çok ayrıntılı bir şekilde açıklanmış durumda, , ama kim böyle bir karmaşık zamanda onu okuyacak ki. Orada en azından IP ve maske belirtmenin yeterli olduğu yazıyor, ama laboratuvarımda böyle bir set sorunlu bir şekilde çalıştı ve yukarıda belirtilen şekilde genişletmek zorunda kaldım.
Editörden çıktıktan sonra update_deploy /home/admin/ECS-CommunityEdition/deploy.yml komutunu çalıştırmalısınız ve her şey doğru yapıldıysa, bununla ilgili açık bir bildirim alacaksınız.
Ardından, yine de videployu çalıştırmanız, ortamın güncellenmesini beklemeniz ve ardından kurulumun ilk adımını ova-step1 komutunu kullanarak başlatmanız gerekecek. Başarılı bir şekilde tamamlandıktan sonra ise ova-step2 komutunu çalıştırabilirsiniz. Önemli: Scriptlerin çalışmasını elle durdurmayın! Bazı adımlar önemli ölçüde zaman alabilir, ilk denemede çalışmayabilir ve her şeyin bozulmuş gibi görünmesine neden olabilir. Her durumda, scriptin doğal olarak tamamlanmasını beklemelisiniz. Sonunda, yaklaşık olarak şöyle bir mesaj görmelisiniz.
Artık nihayet bize bilinen IP üzerinden WebUI kontrol panelini açabiliriz. Eğer yapılandırma aşamasında değiştirmediysek, varsayılan hesap root/ChangeMe olacaktır. Hemen S3 uyumlu depolama alanımızı kullanmaya başlayabiliriz. HTTP için 9020 ve HTTPS için 9021 portlarında erişilebilir. Yine de, eğer hiçbir şey değiştirilmediyse, access_key: object_admin1 ve secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe şeklinde olacaktır.
Ama fazla ileri gitmeyelim ve sırayla başlayalım.
İlk girişte, şifreyi makul bir şekilde değiştirmeye zorlanacaksınız ki bu tamamen doğru. Ana gösterge paneli son derece anlaşılır, bu yüzden açıkça belli olan metrikleri açıklamaktan daha ilginç bir şey yapalım. Örneğin, depolamaya erişim için kullanacağımız bir kullanıcı oluşturalım. Bu sektörde hizmet sağlayıcılar arasında bunlara tenant deniyor. Bunu Manage > Users > New Object User kısmında yapıyoruz.
Kullanıcı oluştururken, bizden bir namespace belirtmemiz istenir. Teknik olarak, isteyen her kullanıcı için istediğimiz kadar oluşturulmasına hiçbir engel yok. Aksine, bu her bir tenant için kaynakları bağımsız bir şekilde yönetmemizi sağlıyor.
İhtiyaç duyduğumuz işlevleri seçerek kullanıcı anahtarlarını oluşturuyoruz. S3/Atmos yeterli olacak benim için. Anahtarı kaydetmeyi unutmuyoruz 😉.
Kullanıcıyı oluşturduk, şimdi ona bir bucket ayırma zamanı. Manage > Bucket bölümüne geçin ve gerekli alanları doldurun. Burada her şey oldukça basit.
Artık S3 depolama alanımızı savaşmaya hazır bir şekilde kullanmaya başlayabiliriz.
Veeam'i ayarlıyoruz.
Beləliklə, xatırladığımız kimi, obyektdə saxlama sistemlərinin ən başlıca tətbiqlərindən biri nadir hallarda əldə edilən məlumatların uzunmüddətli saxlanmasıdır. Uzaq ərazidə arxivlərin saxlanması ehtiyacı mükəmməl bir nümunədir. Veeam Backup & Replication-də bu funksiyaya Capacity Tier deyilir.
Quraşdırmaya başlayaraq, Dell ECS CE-ni Veeam interfeysinə əlavə edəcəyik. Backup Infrastructure tabında yeni bir repository əlavə etmə ustası başlayırıq və Object Storage seçimini seçirik.
Hər şeyin səbəbi olanı seçirik — S3 Compatible.
Açılan pəncərədə istədiyimiz adı yazırıq və Account mərhələsinə keçirik. Burada Service point-i göstərməliyik, forma belədir , bölgəni olduğu kimi saxlaya bilərik və yaradılmış istifadəçini əlavə edirik. Gateway server uzaq ərazidə saxlanılırsa zəruridir, lakin bu artıq infrastrukturun optimallaşdırılması və ayrı bir yazının mövzusudur, belə ki, buranı arxada qoya bilərik.
Hər şey düzgünsə və düzgün tənzimlənibsə, sertifikat barədə xəbərdarlıq görəcəyik, sonra isə fayllarımız üçün qovluq yaratmağımıza imkan verən baket pəncərəsi açılacaq.
Wizard-dan sonuna qədər keçin və nəticədən zövq alın.
Növbəti addımda ya yeni bir Scale-out Backup Repository yaratmalıyıq, ya da var olan S3-ü əlavə etməliyik — bu, arxiv saxlanması üçün Capacity Tier olaraq istifadə olunacaq. Mövcud versiyada S3-ə birbaşa normal repository kimi istifadə etməyə imkan verən funksiyalar yoxdur. Həmin məsələ üçün həll edilməli bir çox qeyri-müəyyən problem var, lakin hər şey mümkündür.
Repository-in tənzimləmələrinə daxil oluruq və Capacity Tier-i aktivləşdiririk. Orada hər şey şaffafdır, lakin maraqlı bir nüans var: bütün məlumatların mümkün qədər tez obyektdə saxlama sisteminə göndərilməsini istəsəniz, sadəcə 0 gün qoyun.
Wizard-dan keçdikdən sonra, gözləmək istəmirsinizsə, repository-yə ctrl+PCM klikləyib Tiering job-u zorla başlada və qrafiklərin necə irəlilədiyini izləyə bilərsiniz.
Bu qədər. Blok saxlama sistemlərinin düşündüyünüz qədər qorxulu olmadığını nümayiş etdirmək vəzifəsi ilə uğur qazandığımı düşünüram. Bəli, həll yolları və icra variantları çoxdur, amma bir yazıda hamısını əhatə etmək mümkün deyil. Buna görə də, təcrübəmizi şərhlərdə bölüşək.
Mənbə: habr.com
