Herkese selam. Bu makale, hala sanallaştırma platformları seçimi arasında kalanlar için ve "Proxmox'u kurduk ve genel olarak her şey yolunda, tek bir ara vermeden 6 yıl çalışma süresi" dizisindeki makaleyi okuduktan sonra yazılmıştır. Ancak kullanıma hazır bir çözümü veya başka bir çözümü kurduktan sonra şu soru ortaya çıkıyor: İzlemeyi daha anlaşılır hale getirmek için bunu burada nasıl düzeltebilirim ve burada yedeklemeleri kontrol etmek için…. Ve sonra zamanı gelir ve daha işlevsel bir şey istediğinizi veya bu kara kutunun değil, sisteminizdeki her şeyin netleşmesini istediğinizi veya bir hiper yönetici ve bir grup sanal makineden daha fazlasını kullanmak istediğinizi fark edersiniz. Bu makale Opennebula platformuna dayalı bazı düşünceler ve uygulamalar içerecektir - bunu seçtim çünkü. kaynak gerektirmez ve mimarisi o kadar karmaşık değildir.
Ve gördüğümüz gibi birçok bulut sağlayıcısı kvm üzerinde çalışıyor ve makineleri kontrol etmek için harici bağlantılar kuruyor. Büyük barındırma sağlayıcılarının bulut altyapısı için kendi çerçevelerini, örneğin aynı YANDEX'i yazdıkları açıktır. Birisi openstack kullanıyor ve bu temelde bağlantı kuruyor - SELECTEL, MAIL.RU. Ancak kendi donanımınız ve küçük bir uzman kadronuz varsa, genellikle hazır bir şeyi seçersiniz - VMWARE, HYPER-V, ücretsiz ve ücretli lisanslar vardır, ancak şu anda bahsettiğimiz şey bu değil. Meraklılardan bahsedelim - bunlar, şirketin "Sizden sonra buna kim hizmet edecek", "Bunu daha sonra üretime geçirecek miyiz" şeklinde açıkça belirtmesine rağmen, yeni bir şey sunmaktan ve denemekten korkmayanlardır. ? Korkutucu." Ancak bu çözümleri önce bir test tezgahında uygulayabilirsiniz ve eğer herkes bundan hoşlanırsa, o zaman daha fazla geliştirme ve daha ciddi ortamlarda kullanma sorununu gündeme getirebilirsiniz.
Ayrıca raporun linki de burada Bu platformun geliştirilmesinde aktif bir katılımcıdan.
Belki bu makalede deneyimli bir uzman için gereksiz ve zaten anlaşılır bir şey olacak ve bazı durumlarda benzer komutlar ve açıklamalar internette mevcut olduğu için her şeyi açıklamayacağım. Bu sadece benim bu platformdaki deneyimim. Aktif katılımcıların yorumlarına nelerin daha iyi yapılabileceğini ve ne gibi hatalar yaptığımı ekleyeceğini umuyorum. Tüm eylemler farklı özelliklere sahip 3 bilgisayardan oluşan bir ev standında gerçekleşti. Ayrıca bu yazılımın nasıl çalıştığını ve nasıl kurulacağını özellikle belirtmedim. Hayır, sadece yönetim tecrübem ve karşılaştığım sorunlar. Belki bu, kendi seçiminde olan biri için faydalı olacaktır.
Öyleyse başlayalım. Bir sistem yöneticisi olarak aşağıdaki noktalar benim için önemlidir ve bunlar olmadan bu çözümü kullanmam pek olası değildir.
1. Kurulumun tekrarlanabilirliği
Opennebula'yı kurmak için pek çok talimat var, herhangi bir sorun olmamalı. Sürümden sürüme, sürümden sürüme geçerken her zaman işe yaramayacak yeni özellikler ortaya çıkıyor.
2. İzleme
Düğümün kendisini, kvm'yi ve açık bulutsusu izleyeceğiz. Neyse ki, zaten hazır. Linux ana bilgisayarlarını, aynı Zabbix'i veya düğüm ihracatçısını (kim neyi daha çok severse) izleme konusunda pek çok seçenek var, şu anda bunu zabbix aracılığıyla sistem metriklerini (ölçülebileceği sıcaklık, disk dizisinin tutarlılığı) izlemek olarak tanımlıyorum. ve Prometheus ihracatçısı aracılığıyla yapılan uygulamalara gelince. Örneğin kvm izleme için projeyi alabilirsiniz ve systemd üzerinden çalışacak şekilde ayarlayın, oldukça iyi çalışıyor ve kvm metriklerini gösteriyor, ayrıca hazır bir kontrol paneli var .
Örneğin, işte benim dosyam:
/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter
[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"
[Install]
WantedBy=multi-user.targetVe böylece 1 ihracatçımız var, açık bulutsunun kendisini izlemek için ikincisine ihtiyacımız var, bunu kullandım
Normale eklenebilir sistemi izlemek için aşağıdakileri yapın.
node_exporter dosyasında başlangıcı şu şekilde değiştiriyoruz:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorBir dizin oluşturun mkdir -p /var/lib/opennebula_exporter
yukarıda sunulan bash betiğinin çalışmasını önce konsol üzerinden kontrol ediyoruz, eğer ihtiyacımız olanı gösteriyorsa (hata veriyorsa xmlstarlet'i kurun), /usr/local/bin/opennebula_exporter.sh dizinine kopyalayın.
Her dakika için bir cron görevi ekleyin:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metrikler ortaya çıkmaya başladı, bunları bir prometheus gibi alıp grafikler oluşturup uyarılar yapabiliyorsunuz. Grafana'da örneğin bu kadar basit bir kontrol paneli çizebilirsiniz.
(burada CPU ve RAM'i aştığım açık)
Zabbix'i seven ve kullananlar için
İzleme söz konusu olduğunda asıl önemli olan onun orada olmasıdır. Elbette yerleşik sanal makine izleme araçlarını kullanabilir ve faturalandırmaya veri yükleyebilirsiniz, burada herkesin kendi vizyonu var, bunun üzerinde henüz daha yakından çalışmaya başlamadım.
Henüz kayıt yapmaya başlamadım. En basit seçenek, /var/lib/one dizinini normal ifadelerle ayrıştırmak için td-agent eklemektir. Örneğin sunstone.log dosyası, nginx regexp ve platforma erişim geçmişini gösteren diğer dosyalarla eşleşir - bunun avantajı nedir? Peki örneğin “Hata, hata” sayısını net bir şekilde takip edip, nerede ve ne düzeyde arıza olduğunu hızlı bir şekilde takip edebiliyoruz.
3. Yedeklemeler
Ayrıca ücretli tamamlanmış projeler de vardır - örneğin eylül :OpenNebula_Backup. Burada, bir makine görüntüsünü yedeklemenin bu durumda hiç de aynı olmadığını anlamalıyız, çünkü sanal makinelerimizin tam entegrasyonla çalışması gerekir (uygulamalarınız için ağ ayarlarını, sanal makine adını ve özel ayarları açıklayan aynı içerik dosyası) . Dolayısıyla neyi, nasıl yedekleyeceğimize burada karar veriyoruz. Bazı durumlarda sanal makinenin kendisinde bulunanların kopyalarını oluşturmak daha iyidir. Ve belki de belirli bir makineden yalnızca bir diski yedeklemeniz gerekir.
Örneğin, tüm makinelerin kalıcı görüntülerle başladığını belirledik, bu nedenle okuduktan sonra
Bu, ilk önce görüntüyü sanal makinemizden yükleyebileceğimiz anlamına gelir:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.İnternetten de buldum ve daha fazlası var , ancak yalnızca qcow2 için depolama alanı var.
Ancak hepimizin bildiği gibi, er ya da geç artımlı yedeklemeler istediğiniz bir zaman gelir, burada bu daha zordur ve belki de yönetim ücretli bir çözüm için para tahsis eder ya da diğer tarafa giderek burada yalnızca kaynakları azalttığımızı anlayacaktır. ve uygulama düzeyinde yedeklemeler yapmak ve bir dizi yeni düğüm ve sanal makine eklemek - evet, burada bulutu yalnızca uygulama kümelerini başlatmak için kullanmak ve veritabanını başka bir platformda başlatmak veya hazır bir platform almaktan bahsediyorum mümkünse tedarikçiden.
4. Kullanım kolaylığı
Bu paragrafta karşılaştığım sorunları anlatacağım. Örneğin görsellere göre bildiğimiz gibi kalıcılık vardır - bu görüntü bir sanal makineye bağlandığında tüm veriler bu görüntüye yazılır. Kalıcı değilse görüntü depoya kopyalanır ve veriler kaynak görüntüden kopyalanana yazılır - şablon şablonları bu şekilde çalışır. Kalıcı belirtmeyi unutarak defalarca kendim için sorun yarattım ve 200 GB'lık görüntü kopyalandı, sorun şu ki bu prosedür kesinlikle iptal edilemiyor, düğüme gidip mevcut "cp" işlemini sonlandırmanız gerekiyor.
Önemli dezavantajlarından biri, yalnızca GUI'yi kullanarak eylemleri iptal edememenizdir. Daha doğrusu iptal edeceksiniz ve hiçbir şey olmadığını göreceksiniz ve yeniden başlatacaksınız, iptal edeceksiniz ve aslında zaten görüntüyü kopyalayan 2 cp işlemi olacak.
Ve sonra sıra, opennebula'nın neden her yeni örneği yeni bir kimlikle numaralandırdığını anlamaya geliyor; örneğin, aynı proxmox'ta kimliği 101 olan bir sanal makine oluşturdu, onu sildi, sonra onu yeniden oluşturdunuz ve kimliği 101 oldu. Opennebula'da bu olmayacak, her yeni örnek yeni bir kimlikle oluşturulacaktır ve bunun kendi mantığı vardır; örneğin eski verilerin temizlenmesi veya başarısız kurulumlar.
Aynı şey depolama için de geçerli; en önemlisi bu platform merkezi depolamayı hedefliyor. Yerel kullanmak için eklentiler var ancak bu durumda bahsettiğimiz şey bu değil. Gelecekte birisinin yerel depolamayı düğümlerde nasıl kullanmayı başardıkları ve üretimde başarıyla kullanmayı nasıl başardıkları hakkında bir makale yazacağını düşünüyorum.
5. Maksimum basitlik
Elbette ne kadar ileri giderseniz sizi anlayacak olanlar da o kadar azalıyor.
Standımın koşulları altında - nfs depolamalı 3 düğüm - her şey yolunda çalışıyor. Ancak, örneğin bir anlık görüntüyü çalıştırırken ve düğümün gücünü kapatırken elektrik kesintisi içeren deneyler yaparsak, bir anlık görüntünün olduğu ayarları veritabanına kaydederiz, ancak aslında böyle bir şey yoktur (hepimiz anlıyoruz ki başlangıçta bu eylemle ilgili veritabanını sql'de yazdı, ancak işlemin kendisi başarılı olmadı). Avantajı, anlık görüntü oluştururken ayrı bir dosya oluşması ve bir "ana" bulunmasıdır, bu nedenle sorun olması durumunda ve gui aracılığıyla çalışmasa bile qcow2 dosyasını alıp ayrı olarak geri yükleyebiliriz.
Ağlarda maalesef her şey o kadar basit değil. En azından openstack'tan daha kolay, sadece vlan (802.1Q) kullandım - oldukça iyi çalışıyor, ancak şablon ağındaki ayarlarda değişiklik yaparsanız, bu ayarlar halihazırda çalışan makinelere uygulanmayacaktır, yani. bir ağ kartını silip eklemeniz gerekir, ardından yeni ayarlar uygulanacaktır.
Hala openstack ile karşılaştırmak istiyorsanız şunu söyleyebilirsiniz: opennebula'da veri depolamak, ağı yönetmek, kaynaklar için hangi teknolojilerin kullanılacağına dair net bir tanım yoktur - her yönetici kendisi için neyin daha uygun olduğuna kendisi karar verir.
6. Ek eklentiler ve kurulumlar
Sonuçta anladığımız kadarıyla bulut platformu yalnızca kvm'yi değil aynı zamanda vmware esxi'yi de yönetebiliyor. Maalesef Vcenter'da havuzum olmadı, deneyen varsa yazsın lütfen.
Diğer bulut sağlayıcılarına yönelik destek belirtildi
AWS, AZURE.
Vmware Cloud'u Selectel'den de bağlamayı denedim, ancak hiçbir şey işe yaramadı - genel olarak engellendi çünkü birçok faktör var ve barındırma sağlayıcısının teknik desteğine yazmanın bir anlamı yok.
Ayrıca, artık yeni sürümde havai fişek var - bu, docker üzerinde bir tür kvm koşum takımı olan microvm'nin lansmanıdır; bu, daha fazla çok yönlülük, güvenlik ve artan üretkenlik sağlar çünkü ekipmanı taklit etmek için kaynak israfına gerek yoktur. Docker'a göre gördüğüm tek avantaj, fazladan işlem gerektirmemesi ve bu emülasyonu kullanırken dolu soketlerin olmamasıdır; Yük dengeleyici olarak kullanmak oldukça mümkün (ancak tüm testleri tam olarak yapana kadar bunun hakkında ayrı bir makale yazmaya değer muhtemelen).
7. Olumlu kullanım deneyimi ve hata ayıklama
Çalışmayla ilgili gözlemlerimi paylaşmak istedim, bir kısmını yukarıda anlattım, daha fazlasını yazmak isterim. Aslında, ilk başta bunun doğru sistem olmadığını ve genel olarak buradaki her şeyin bir koltuk değneği olduğunu düşünen tek kişi muhtemelen ben değilim - bununla nasıl çalışıyorlar? Ama sonra her şeyin oldukça mantıklı olduğu anlayışı geliyor. Elbette herkesi memnun edemezsiniz ve bazı yönlerin geliştirilmesi gerekiyor.
Örneğin, bir disk görüntüsünü bir veri deposundan diğerine kopyalamak gibi basit bir işlem. Benim durumumda, nfs'li 2 düğüm var, görüntüyü gönderiyorum - kopyalama ön uç opennebula aracılığıyla gerçekleşir, ancak hepimiz verilerin doğrudan ana bilgisayarlar arasında kopyalanması gerektiği gerçeğine alışkınız - aynı vmware'de, hyper-v'deyiz buna alıştım, ama burada diğerine. Farklı bir yaklaşım ve farklı bir ideoloji var ve 5.12 sürümünde "veri deposuna taşı" düğmesini kaldırdılar - yalnızca makinenin kendisi aktarılır, ancak depolama aktarılmaz çünkü merkezi depolama anlamına gelir.
Sırada çeşitli nedenleri olan popüler bir hata var: "Sanal makine dağıtılırken hata: /var/lib/one//datastores/103/10/deployment.5'ten etki alanı oluşturulamadı" Bakılması gereken en önemli şey aşağıdadır.
- Oneadmin kullanıcısı için resim hakları;
- Oneadmin kullanıcısının libvirtd'yi çalıştırma izinleri;
- Veri deposu doğru şekilde monte edilmiş mi? Gidin ve düğümdeki yolu kontrol edin, belki bir şeyler düşmüş olabilir;
- Yanlış yapılandırılmış ağ veya daha doğrusu ön uçta, ağ ayarlarında vlan için ana arayüz br0'dır, ancak düğümde köprü0 olarak yazılmıştır - aynı olmalıdır.
sistem veri deposu sanal makineniz için meta verileri saklar; sanal makineyi kalıcı bir görüntüyle çalıştırırsanız sanal makinenin, sanal makineyi oluşturduğunuz depolama alanında başlangıçta oluşturulan yapılandırmaya erişmesi gerekir - bu çok önemlidir. Bu nedenle, bir sanal makineyi başka bir veri deposuna aktarırken her şeyi iki kez kontrol etmeniz gerekir.
8. Belgeler, topluluk. Daha fazla gelişme
Ve geri kalanı, iyi dokümantasyon, topluluk ve asıl önemli olan, projenin gelecekte yaşamaya devam etmesidir.
Genel olarak, her şey oldukça iyi belgelenmiştir ve resmi bir kaynak kullanılarak bile kurulum ve soruların yanıtlarını bulmak sorun olmayacaktır.
Topluluk, aktif. Tesisatlarınızda kullanabileceğiniz birçok hazır çözümü yayınlamaktadır.
Şu anda şirketteki bazı politikalar 5.12'den bu yana değişti Projenin nasıl gelişeceğini görmek ilginç olacak. Başlangıçta, çözümlerini kullanan bazı satıcıları ve sektörün sunduklarını özellikle belirttim. Elbette ne kullanılacağı konusunda net bir cevap yok. Ancak daha küçük kuruluşlar için küçük özel bulutlarının bakımı göründüğü kadar pahalı olmayabilir. Önemli olan tam olarak neye ihtiyacınız olduğunu bilmektir.
Sonuç olarak bulut sistemi olarak ne seçerseniz seçin tek bir üründe kalmamalısınız. Zamanınız varsa daha açık çözümlere göz atmakta fayda var.
Güzel bir sohbet var Aktif olarak yardımcı oluyorlar ve sizi Google'da soruna çözüm aramaya göndermiyorlar. Bize katılın.
Kaynak: habr.com