Felaket Kurtarma çözümleri pazarındaki genç oyunculardan biri, 2016'da bir Rus girişimi olan Hystax'tır. Olağanüstü durum kurtarma konusu çok popüler olduğundan ve pazar son derece rekabetçi olduğundan, girişim, farklı bulut altyapıları arasında geçişe odaklanmaya karar verdi. Buluta basit ve hızlı bir geçiş düzenlemenizi sağlayan bir ürün, Onlanta'nın müşterileri - kullanıcıları için çok faydalı olacaktır. . Böylece Hystax ile tanıştım ve özelliklerini test etmeye başladım. Ve bundan ne çıktı, bu makalede anlatacağım.
Hystax'ın ana özelliği, çeşitli sanallaştırma platformlarını, konuk işletim sistemlerini ve bulut hizmetlerini desteklemeye yönelik geniş işlevselliğidir ve bu da iş yüklerinizi her yerden ve her yerden taşımanıza olanak tanır.
Bu, yalnızca hizmetlerin hata toleransını iyileştirmek için DR çözümleri oluşturmanıza değil, aynı zamanda maliyet tasarrufunu artırmak ve belirli bir hizmet için o anda en iyi çözümü seçmek için kaynakları farklı siteler ve hiper ölçekleyiciler arasında hızlı, esnek bir şekilde taşımanıza olanak tanır. Şirket, başlık resminde listelenen platformlara ek olarak, Rus bulut sağlayıcılarıyla da aktif olarak işbirliği yapıyor: Yandex.Cloud, CROC Bulut Hizmetleri, Mail.ru ve diğerleri. 2020 yılında şirketin Skolkovo'da bir Ar-Ge merkezi açtığını da belirtmekte fayda var.
Piyasadaki çok sayıda oyuncunun tek bir çözümü seçmesi, pratikte test etmeye karar verdiğimiz ürünün iyi bir fiyat politikasına ve yüksek uygulanabilirliğine işaret ediyor.
Bu nedenle test görevimiz, VMware test sitemden ve fiziksel makinelerimden sağlayıcının yine VMware çalıştıran sitesine geçiş yapmaktan oluşacak. Evet, böyle bir taşımayı gerçekleştirebilecek pek çok çözüm var, ancak Hystax'ı evrensel bir araç olarak görüyoruz ve taşımayı tüm olası kombinasyonlarda test etmek gerçekçi olmayan bir görev. Evet ve Oncloud.ru bulutu özellikle VMware üzerine inşa edilmiştir, bu nedenle bu platform bir hedef olarak bizi daha fazla ilgilendiriyor. Daha sonra, bir bütün olarak platforma bağlı olmayan temel çalışma prensibini açıklayacağım ve VMware herhangi bir yönden başka bir satıcının platformuyla değiştirilebilir.
İlk adım, sistemin kontrol paneli olan Hystax Acura'yı devreye almaktır.
Şablondan genişler. Nedense bizim durumumuzda bu tamamen doğru değildi ve önerilen 8CPU yerine kaynakların yarısıyla 16Gb konuşlandırıldı. Bu nedenle, bunları değiştirmeyi hatırlamanız gerekir, aksi takdirde VM içindeki her şeyin üzerine inşa edildiği altyapı kapsayıcılarla başlamaz ve portal kullanılamaz hale gelir. İÇİNDE gerekli kaynaklar ve ayrıca tüm sistem bileşenleri için bağlantı noktaları ayrıntılı olarak açıklanmıştır.
Ayrıca şablon aracılığıyla IP adresini ayarlamada zorluklar vardı, bu yüzden onu konsoldan değiştirdik. Bundan sonra yönetici web arayüzüne gidebilir ve ilk yapılandırma sihirbazını tamamlayabilirsiniz.
Uç nokta - vCenter'ımızın IP veya FQDN'si.
Giriş ve Şifre - burada açık.
Hedef ESXi ana bilgisayar adı, kümemizde çoğaltılacak ana bilgisayarlardan biridir.
Hedef veri deposu, kümemizdeki çoğaltılacak veri depolarından biridir.
Hystax Acura Kontrol Paneli Genel IP - kontrol panelinin mevcut olacağı adres.
Ana bilgisayar ve veri deposu hakkında biraz açıklama gerekiyor. Gerçek şu ki Hystax çoğaltması, ana bilgisayar ve veri deposu düzeylerinde çalışır. Ardından, kiracı için ana bilgisayarı ve veri deposunu nasıl değiştirebileceğinizi anlatacağım, ancak sorun farklı. Hystax, kaynak havuzlamayı desteklemez, örn. çoğaltma her zaman kümenin kökünde olacaktır (bu materyali yazarken, Hystax'tan adamlar, kaynak havuzları desteğiyle ilgili özellik isteğimi hızlı bir şekilde uyguladıkları güncellenmiş bir sürüm yayınladılar). Ayrıca vCloud Director desteklenmez, yani. benim durumumda olduğu gibi, kiracı tüm küme üzerinde değil, yalnızca belirli bir kaynak havuzunda yönetici haklarına sahipse ve Hystax'a erişim vermişsek, o zaman bu VM'leri bağımsız olarak çoğaltabilir ve çalıştırabilir, ancak bunları erişemediği VMware altyapısında göremez ve buna bağlı olarak sanal makineleri daha fazla yönetemez. Küme yöneticisinin VM'yi doğru kaynak havuzuna taşıması veya vCloud Director'a aktarması gerekir.
Neden bu anlara bu kadar çok odaklanıyorum? Çünkü, ürün konseptini anladığım kadarıyla müşteri, Acura panelini kullanarak herhangi bir taşımayı veya DR'yi bağımsız olarak uygulayabilmelidir. Ancak şimdiye kadar, VMware desteği, bu tür mekanizmaların zaten uygulanmış olduğu aynı OpenStack için destek seviyesinin biraz gerisindedir.
Ancak konuşlandırmaya geri dönelim. Öncelikle panelin ilk kurulumundan sonra sistemimizde ilk kiracıyı oluşturmamız gerekiyor.
Buradaki tüm alanlar açık, ben size sadece Bulut alanından bahsedeceğim. İlk yapılandırma sırasında oluşturduğumuz bir "varsayılan" bulutumuz zaten var. Ancak her kiracıyı kendi veri deposuna ve kendi kaynak havuzuna koyabilmek istiyorsak bunu her bir müşterimiz için ayrı bulutlar oluşturarak hayata geçirebiliriz.
Yeni bir bulut ekleme biçiminde, ilk yapılandırma sırasındakiyle aynı parametreleri belirtiyoruz (aynı ana bilgisayarı bile kullanabiliriz), belirli bir müşteri için gereken veri deposunu belirtiyoruz ve şimdi ek parametrelerde, gerekli havuz kaynağı {"resource_pool" :"YOUR_POOL_NAME"}
Fark etmiş olabileceğiniz gibi, kiracı oluşturma şeklinde kaynakların tahsisi veya bir tür kotalar hakkında hiçbir şey yoktur - sistemde bunlardan hiçbir şey yoktur. Kiracıyı eşzamanlı çoğaltma sayısı, çoğaltma için makine sayısı veya başka herhangi bir parametre ile sınırlayamazsınız. Böylece ilk kiracıyı oluşturduk. Artık tamamen mantıklı değil, zorunlu bir şey var - bir Bulut aracısı kurmak. Mantıksız, çünkü temsilci belirli bir müşterinin sayfasında indiriliyor.
Aynı zamanda, oluşturulan kiracıya bağlı değildir ve tüm müşterilerimiz bunun üzerinden (veya dağıtırsak birkaçından sonra) çalışacaktır. Bir aracı, 10 eşzamanlı oturumu destekler. Bir seans bir araba olarak sayılır. Kaç disk olduğu önemli değil. Bugüne kadar, VMware için Acura'nın kendisinde ajanları ölçeklendirmek için bir mekanizma yoktur. Hoş olmayan bir an daha var - daha fazla dağıtmamız gerekip gerekmediğine veya mevcut kurulumun yeterli olup olmadığına karar vermek için Acura panelinden bu aracının "kullanımına" bakamıyoruz. Sonuç olarak, stand şöyle görünür:
Müşterimizin portalına erişmenin bir sonraki adımı, bir hesap (ve önce bu kullanıcıya uygulanacak bir rol) oluşturmaktır.
Artık müşterimiz portalı bağımsız olarak kullanabilir. Tek yapması gereken, portaldan ajanları indirip kendi tarafına yüklemek. Üç tür ajan vardır: Linux, Windows ve VMware.
İlk ikisi, VMware olmayan herhangi bir hipervizörde fiziğe veya sanal makinelere konur. Burada gerekli ek yapılandırma yoktur, aracı indirir ve zaten nereye vuracağını bilir ve kelimenin tam anlamıyla bir dakika içinde araba Acura panelinde görünür olacaktır. VMware aracısı ile durum biraz daha karmaşıktır. Sorun, Agent for VMware'in önceden hazırlanmış ve gerekli yapılandırmaya sahip portaldan indirilmesidir. Ancak VMware aracısının, Acura portalımız hakkında bilgi sahibi olmasının yanı sıra, konuşlandırılacağı sanallaştırma sistemi hakkında da bilgi sahibi olması gerekir.
Aslında, VMware aracısını ilk indirdiğinizde sistem bizden bu verileri belirtmemizi isteyecektir. Sorun şu ki, evrensel güvenlik sevgisi çağımızda, herkes yönetici şifresini bir başkasının portalında belirtmek istemeyecektir ki bu oldukça anlaşılır bir durumdur. İçeriden dağıtımdan sonra aracı hiçbir şekilde yapılandırılamaz (yalnızca ağ ayarlarını değiştirebilirsiniz). Burada özellikle temkinli müşterilerle ilgili zorluklar öngörüyorum.
Böylece aracıları kurduktan sonra Acura paneline geri dönebilir ve tüm arabalarımızı görebiliriz.
Bir günden fazla süredir sistemle çalıştığım için çeşitli statlarda makinelerim var. Hepsi Default grubunda yer alıyor ancak ihtiyacınıza göre ayrı gruplar oluşturup makineleri bunlara aktarmanız mümkün. Bu hiçbir şeyi etkilemez - yalnızca verilerin mantıksal temsili ve daha rahat çalışma için gruplandırılması. Bundan sonra yapmamız gereken ilk ve en önemli şey geçiş sürecini başlatmaktır. Bunu hem zorla manuel olarak yapabiliyoruz hem de tüm makineler için aynı anda toplu olmak üzere bir çizelge oluşturabiliyoruz.
Hystax'ın bir geçiş ürünü olarak konumlandırıldığını hatırlatmama izin verin. Bu nedenle, çoğaltılmış makinelerimizi çalıştırmak için bir DR planı oluşturmamız şaşırtıcı değildir. Halihazırda Eşitlendi durumunda olan makineler için bir plan oluşturabilirsiniz. Hem belirli bir VM için hem de tüm makineler için aynı anda oluşturabilirsiniz.
Bir felaket kurtarma planı oluştururken parametre seti, geçiş yapacağınız altyapıya bağlı olarak farklılık gösterecektir. Bir VMware ortamı için minimum sayıda seçenek mevcuttur. Makineler için yeniden IP de desteklenmez. Bu bağlamda, aşağıdaki noktalarla ilgileniyoruz: VM'nin açıklamasında, VM'yi kümedeki belirli bir ağa bağladığımız "alt ağ" parametresi: "VMNetwork". Derece - birkaç VM'yi taşırken alakalıdır ve başlatıldıkları sırayı belirler. Flavour, VM yapılandırmasını, bu durumda 1CPU, 2GB RAM'i açıklar. Alt ağlar bölümünde, "alt ağ" tanımlıyoruz: "VMNetwork", VMware'in "VM Ağı" ile ilişkilidir.
Bir DR planı oluştururken, diskleri farklı veri depolarına "bölmenin" bir yolu yoktur. Bu istemci bulutu için tanımlanan aynı veri deposunda yer alacaklar ve farklı sınıflarda diskleriniz varsa, bu, makineyi başlatırken bazı zorluklara neden olabilir ve VM'yi başlattıktan ve Hystax'tan "ayırdıktan" sonra, aynı zamanda gerekli veri depolarına ayrı bir geçiş diski gerektirir. O zaman DR planımızı çalıştırmamız ve arabalarımızın yükselmesini beklememiz gerekiyor. P2V/V2V dönüştürme işlemi de zaman alır. Üç diskli en büyük 100 GB test makinemde bu işlem maksimum 10 dakika sürdü.
Bundan sonra çalışan VM'yi, üzerindeki hizmetleri, veri tutarlılığını ve diğer kontrolleri kontrol etmelisiniz.
O zaman iki seçeneğimiz var:
- Sil - çalışan bir acil durum planını silin. Bu eylem, çalışan VM'yi basitçe kapatacaktır. Bu kopyalar hiçbir yere gitmiyor.
- Ayırın - çoğaltılan arabayı Acura'dan ayırın, yani. aslında taşıma işlemini tamamlayın.
Çözümün avantajları:
- hem istemci tarafında hem de sağlayıcı tarafında kurulum ve yapılandırma kolaylığı;
- geçiş ayarlama, bir DR planı oluşturma ve kopyaları başlatma kolaylığı;
- destek ve geliştiriciler, bulunan sorunlara oldukça hızlı yanıt verir ve bunları platform veya aracı güncellemeleriyle düzeltir.
Eksileri
- Yetersiz Vmware desteği.
- Platformdan kiracılar için herhangi bir kota olmaması.
Ayrıca satıcıya ilettiğimiz bir Özellik İsteği yaptım:
- Bulut Aracıları için Acura Yönetim Konsolundan kullanım izleme ve devreye alma;
- kiracılar için kotaların mevcudiyeti;
- her kiracı için eşzamanlı çoğaltma sayısını ve hızı sınırlama yeteneği;
- VMware vCloud Director desteği;
- kaynak havuzları için destek (test sırasında uygulandı);
- Acura panelinde istemci altyapısından kimlik bilgilerini girmeden VMware aracısını aracının kendi tarafından yapılandırma yeteneği;
- Bir DR planı başlatırken bir VM başlatma sürecinin "görselleştirilmesi".
Bana büyük şikayetlere neden olan tek şey belgelerdi. "Kara kutuları" gerçekten sevmiyorum ve ürünün içinde nasıl çalıştığına dair ayrıntılı belgeler olmasını tercih ediyorum. Ve AWS ve OpenStack için ürün aşağı yukarı açıklanıyorsa, o zaman VMware için çok az belge vardır.
Yalnızca Acura panelinin dağıtımını açıklayan ve bir Bulut aracısına duyulan ihtiyaç hakkında tek bir kelimenin olmadığı bir Kurulum Kılavuzu vardır. Ürün için iyi bir özellik seti var. Örnek olarak AWS ve OpenStack'i kullanarak "başlangıçtan ve bitişe" kurulumu açıklayan belgeler var (her ne kadar bana daha çok bir blog gönderisini hatırlatıyor olsa da) ve çok küçük bir Bilgi Bankası var.
Genel olarak, bu, örneğin daha büyük satıcılardan alışık olduğum dokümantasyon formatı değil, bu yüzden tamamen rahat değildim. Aynı zamanda, bu dokümantasyonda sistemin "içeride" çalışmasına ilişkin bazı nüanslar hakkında yanıtlar bulamadım - teknik destekle birçok soruyu açıklığa kavuşturmak zorunda kaldım ve bu, standı yerleştirme sürecini oldukça uzattı ve test yapmak.
Özetle, genel olarak ürünü ve şirketin görevin uygulanmasına yaklaşımını beğendiğimi söyleyebilirim. Evet, kusurlar var, gerçekten kritik bir işlevsellik eksikliği var (VMware ile bağlantılı olarak). Görüldüğü üzere şirketin öncelikle AWS başta olmak üzere genel bulutlara ağırlık verdiği görülüyor ve bu bazıları için yeterli olacaktır. Birçok şirketin çoklu bulut stratejisini seçtiği günümüzde bu kadar basit ve kullanışlı bir ürüne sahip olmak son derece önemlidir. Rakiplerine kıyasla çok daha düşük fiyatı göz önüne alındığında, bu, ürünü son derece çekici kılmaktadır.
bir ekip arıyoruz . Belki de sensin?
Kaynak: habr.com