Yaklaşık 7 yıl önce ilk projeler basit ve gösterişsiz bir şekilde bulutumuza taşındı. Sanal makine görüntüleri bir FTP sunucusuna yüklendi veya sabit sürücülere teslim edildi. Daha sonra özel bir içe aktarma sunucusu aracılığıyla VM'ler buluta yüklendi.
İstemcinin sanal makineyi bir veya iki gün kapatması sorun değilse (veya başka seçenek yoksa), bu yapılabilir. Ancak kesinti süresinin maksimum bir saat olması gerekiyorsa bu yöntem işe yaramayacaktır. Bugün size hangi araçların minimum kesinti süresiyle buluta geçiş yapmanıza yardımcı olacağını ve geçiş sürecimizin nasıl çalıştığını anlatacağım.
Veeam Backup and Replication ile Geçiş
Herkes Veeam Backup and Replication'ın yedekleme ve replika oluşturmaya yönelik bir araç olduğunu bilir. Bunu sitelerimiz arasında geçiş yapmak ve müşterileri özel sanallaştırmadan bulutumuza taşımak için kullanıyoruz. Müşterinin sanal makineleri vCenter'ımıza kopyalanır ve ardından mühendis bunları vCloud Director'a ekler.
Birincil çoğaltma, açık bir sanal makinede gerçekleşir. Kararlaştırılan zamanda istemci tarafındaki makine kapatılır. Çoğaltma, ilk çoğaltmadan bu yana meydana gelen değişiklikleri aktarmak için yeniden çalışır. Bundan sonra sanal makine bulutumuzda başlıyor.
Tipik olarak, makinenin istemcinin altyapısında kapatıldığı andan bulutumuzda açıldığı ana kadar geçen süre yarım saatten fazla değil, 15-20 dakikadır.
Bu durumda orijinal sanal makine istemci sitesinde kalır. Aniden bir şeyler ters giderse, istediğiniz zaman geri alıp açabilirsiniz. Bu yöntem ayrıca müşterinin Veeam'e sahip olmasını gerektirmemesi açısından da uygundur.
Dava 1
Müşterinin VMware'e dayalı kendi sanal altyapısı vardı - 40 TB kapasiteli 30 VM. Kümenin konuşlandırıldığı ekipman zaten güncelliğini kaybetmişti ve müşteri yenilerini satın alma zahmetine girmemeye karar verdi ve genel buluta geçti. Kritik sistemler için kesinti süresi gereksinimi bir saatten fazla değildi. Araç olarak Veeam Replication seçildi. Bir diğer artı da müşterinin internet sağlayıcısının veri merkezimizde mevcut olması, iyi bir kanal düzenlemeyi mümkün kılıyordu. Geçiş yaklaşık bir ay sürdü; geçiş sırasındaki kesinti süresi, sanal makine grubu başına 30 dakikaya kadar çıktı.
Veeam Cloud Connect ile Geçiş Yapın
Veeam Cloud Connect, sanal makine replikasyonu ayarlamanıza ve servis sağlayıcının bulutunda replikaları başlatmanıza yardımcı olan bir araçtır. Güncelleme yaptıktan sonra yıl, sanal makineleri doğrudan vCloud Director'a kopyalamak mümkün hale geldi. Tek koşul istemci tarafında Veeam Backup and Replication'ın en az sürüm 9'un konuşlandırılmasıdır. Kısaca (detaylı sürüm) ), o zaman tüm süreç şöyle görünür.
vCloud Director'da gerekli kaynaklara ve ağlara sahip bir organizasyon oluşturulur. Veeam Cloud Connect'te bir hesap oluştururuz, müşteri Veeam B&R'sinden bu hesaba bağlanır, bir DataLine sağlayıcısı ve kuruluşu seçer ve çoğaltma için görevleri yapılandırır. Böyle bir geçiş sırasında kesinti süresinin 15-20 dakika içinde olacağı gerçeğine ek olarak, müşteri hiçbir şekilde sağlayıcının teknik desteğine bağlı değildir ve tüm süreci bağımsız olarak yönetir: çoğaltma görevleri oluşturur, çoğaltmanın kendisi, kapatır makineleri ve onları yeni sitede başlatır.
Dava 2
Geçişin planlandığı müşterinin altyapısı Belarus'ta bulunuyordu. İnternet kanalının 90 Mbit/sn olmasına rağmen toplam hacmi 27 TB olan 100 VM'nin taşınması gerekiyordu. Bir yedekleme yapıp bunu hemen bulutumuza yüklerseniz, bazı VM'ler için bu işlem birkaç gün sürebilir. Bu süre zarfında VM'de büyük bir delta büyüyebilir ve bu durum makinelerin performansını olumsuz etkileyebilir veya daha da kötüsü veri deposundaki alan tükenebilir. Biz şu şekilde ilerledik: Öncelikle müşteri local full backup aldı ve bunun bir kopyasını Veeam Cloud Connect aracılığıyla bulutumuza aktardı. Daha sonra artışı yapıp buluta aktardım. Orijinal sanal makine çalışmaya devam etti. VM'yi kapattıktan sonra istemci bir artış daha yaptı ve onu da buluta aktardı. Bizim tarafımızda, tam yedeklemeden bir sanal makine dağıttık ve ardından bunun üzerine iki artış aktardık. Bu plan sonuçta sitemize geçişte kesinti süresini 2 saate indirmeyi mümkün kıldı.
VMware vCloud Kullanılabilirliği ile Geçiş
Bu yılın Mart ayında VMware, sanal makineleri farklı bulutlar arasında (vCloud Director - vCloud Director) ve özel istemci sanallaştırma standlarından buluta (vCenter - vCloud Director) taşımanıza olanak tanıyan vCloud Availability 3.0'ı piyasaya sürdü. Ana kolaylık, vCloud Director arayüzüyle entegrasyondur. Bu, çoğaltma yönetimi sürecini büyük ölçüde basitleştirir ve geçişler sırasında kesinti süresini en aza indirir.
Bu aracı kullanarak müşterilerimizden birini Moskova bulutumuzdan St. Petersburg'daki bulutumuza taşıdık. Toplam kapasitesi 18 TB olan 14 sanal makinenin taşınması gerekiyordu. Müşteri için St.Petersburg bulutunda bir organizasyon oluşturuldu ve gerekli ağlar düzenlendi. Daha sonra istemci, vCloud Director arayüzünden vCloud Availability ayarlarına gitti, replikasyon işleri oluşturdu ve kendisi için uygun bir zamanda St. Petersburg sitesine geçiş yaptı. Geçiş sırasındaki kesinti süresi 12 dakikaydı.
St. Petersburg ve Moskova'daki DataLine bulutları arasındaki geçiş planı.
vCloud Availability, VM'leri müşterinin sitesinden bulutumuza taşımak için bir mekanizmaya sahiptir. Bunu yapmak için istemcinin vCenter'ında özel bir vCloud Availability uygulaması kurulur. Basit kurulumun ardından buluta bağlanır ve geçiş görevlerini yapılandırırsınız. Müşteri ayrıca tüm süreci bağımsız olarak yönetir ve geçiş süresi minimumda tutulur.
Sanal makineleri özel bir kurulumdan buluta geçirme şeması.
VMware vCloud Availability'nin başka birçok kullanım durumu vardır; yakında ayrı bir makalede bunlardan bahsedeceğiz.
Geçişe hazırlanıyor
Bir araç seçmek ve geçişe gerçekten başlamak için aşağıdaki noktalara karar vermeniz gerekir:
Nereden göç ediyoruz? Özel bir çözümden geçiş yapıyorsanız araç seçiminde tam özgürlüğe sahip olursunuz. Sağlayıcınızdan uzaklaşırsanız durum daha karmaşık hale gelir. Büyük olasılıkla, iki sağlayıcının altyapılarını birbirine bağlamak ve bir VM'yi basitçe sürükleyip bırakmak, güvenlik nedeniyle işe yaramayacaktır. Bazen müşterinin reddetmek üzere olduğu sağlayıcı yaramazlık yapmaya başlar ve zamanı oyalar. Sağlayıcıdan eski yöntemlerle uzaklaşabilirsiniz: VM'leri disklere ve FTP'ye yükleyerek veya uygulama düzeyinde geçiş yaparak. İkincisinin adı koşullu ve buna benzer bir şeye benziyor.
Dava 3
Müşterinin SAP sistemini Avrupalı bir sağlayıcıdan taşımak gerekiyordu: 34 TB kapasiteli 54 VM. Müşteriye bulutumuzdaki kaynaklar tahsis edildi. Avrupalı sağlayıcının altyapısı ile aramızda ağ bağlantısı düzenlendi. Uygulama sunucuları, gerekli yapılandırmalar gözden geçirilerek yeniden konuşlandırıldı. Büyük veritabanları, yedeklerin bulutumuza yüklenmesi yoluyla taşındı. Daha sonra, bizim ve orijinal sitelerimizdeki veritabanları arasında çoğaltma yapılandırıldı. Kararlaştırılan zamanda bulutumuzdaki veritabanlarına geçtik.
Veri hacmi ve İnternet kanalı. Genellikle istemciden bellek, CPU ve disk parametrelerini içeren sisteme göre bir yükleme sağlamasını isteriz. Kanalın sanal makinelerin replikalarını veya yedeklerini doğrudan göndermek için yeterli olup olmadığını değerlendiriyoruz.
Kabul edilebilir aksama süresi. Farklı sistemler ve buna bağlı olarak sanal makineler için iş kritikliklerine bağlı olarak farklı olabilir. Genellikle müşteri, geçiş sırasındaki kesinti süresine ilişkin hazır gereksinimlerle birlikte gelir ve buna dayanarak uygun aracı ve geçiş planını seçeriz. Son geçişi gece veya hafta sonları planlamaya çalışıyoruz, böylece en küçük kesintiler bile müşterinin son kullanıcıları tarafından fark edilmiyor.
Bu verilere dayanarak bir araç seçip taşıma işlemine başlayabilirsiniz. İşte bundan sonra ne olacak.
- Ağ bağlantısını ayarlama. Bulutumuz ile müşterinin altyapısı arasındaki ağ bağlantısını düzenliyoruz. Sanal makineler bu ağ üzerinden kopyalanacaktır. Veeam Backup and Replication kullanılıyorsa bu özel bir kanaldır, daha az sıklıkla bir VPN kanalıdır. Veeam Cloud Connect ise her şey İnternet üzerinden veya aynı özel kanal üzerinden gerçekleşir.
Daha sonra ağ, buluttaki VM için yapılandırılır. Arabalar genellikle gruplar halinde ve bir günden fazla hareket eder. VM'ler bize getirilip başlatıldığında, hala orijinal sitede kalan makinelerle iletişim kurmaları gerekiyor.
- Taşıma planı. Çok fazla araba olduğunda, onları gruplara ayırmak ve gruplar halinde taşımak mantıklıdır. Müşteriyle birlikte, hangi makinelerin ne zaman taşınacağını ve son kopyalamanın ve yeni siteye geçişin ne zaman gerçekleştirileceğini belirleyeceğimiz bir plan üzerinde anlaşıyoruz.
- Geçişi test edin. Test sanal makinesini taşıyoruz ve her şeyin doğru yapılandırılıp yapılandırılmadığını kontrol ediyoruz: siteler arasındaki ağ bağlantısı, sanal makinenin kaynak sitedeki makineler tarafından kullanılabilirliği, hesap hakları vb. Bu test, savaş geçiş aşamasında aksaklıkların önlenmesine yardımcı olur.
Benim için hepsi bu. Yorumlarda sorular sorun ve bize geçiş deneyiminizi anlatın.
Kaynak: habr.com