g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Kurumsal ortamda OpenStack'in otomatik fonksiyon testi

Bu makale, bulut teknolojisi topluluğunun çevrimiçi paylaşımından gelmektedir.

Yazar Xu Chao

Herkese merhaba. Sizlerle "Kurumsal Ortamda OpenStack Otomatik Fonksiyon Testini" veya daha doğrusu API fonksiyon testini paylaşmak bir onurdur. Paylaşılan içerikte bir sorun varsa, lütfen beni düzeltin ve içeriğin net ve anlaşılması kolay olduğundan emin olmak için elimden gelenin en iyisini yapmaya çalışıyorum. Eve yaklaştıkça konuya geçelim.

Bir, OpenStack test özeti

Bulut bilişimin yurtiçi ve yurtdışında hızla gelişmesiyle birlikte, OpenStack bu konuda yerleşik bir fiili standart haline geldi.Birçok şirket OpenStack'e dayalı bulut ürünleri geliştirdiğinde, doğal olarak test gereksinimleri ve kalite için daha yüksek gereksinimler ortaya koydu.

Şu anda, OpenStack topluluğunun yaklaşık yüz projesi, binlerce geliştiricisi, on milyonlarca satır kodu ve katılan yüzlerce şirketi var. OpenStack açık kaynak topluluğunun düzenli, istikrarlı ve sağlıklı gelişimini desteklemek için farklı düzeylere ve farklı amaçlara sahip bu kadar çok geliştiricinin bilgeliğe katkıda bulunmasını ve belirli kurallara göre kod göndermesini nasıl sağlayabilirsiniz. Bu nedenle topluluk, erişim kontrol sistemi anlamına gelen CI (Continuous Integration) -Gate'de bir kural ortaya koydu. Geliştiricilerin kod gönderdiği durumlarda (kapının dışında duran), kod Git deposuna girmeden önce (kapının içinde durarak) başarılı bir şekilde test edilmelidir (erişim kontrol sistemi doğrulanır).

OpenStack testi, çok çeşitli seviyeleri ve çok teknolojili çapraz uygulamaları içeren bir alandır. Farklı seviyelere göre, enlem bölünmesi esas olarak şunları içerir: birim testi > İşlevsel test (entegrasyon testi olarak da adlandırılır) > Sistem testi (kabul testi, performans testi gibi) vb. Belirli test nesnelerine ve hedeflerine göre depolama testi, sanal makine ağ testi, hata HA testi vb. Olarak ayrılabilir. Aşağıda gösterildiği gibi.

Test açısından, OpenStack topluluğu, farklı test seviyeleri için ilgili test araçlarını veya projeleri tasarlayarak ve uygulayarak çok iyi bir iş çıkardı. Spesifik olarak, spesifikasyona uygun olup olmadığını yazmak için Python PEP8 ve diğer test kodunu kullanın, Nose ve diğer çerçeveler birim testi için kullanılır, Tempest fonksiyonel / entegrasyon testi için kullanılır, Rally performans testi için kullanılır, Shaker sanal makine ağ testi için kullanılır, DevStack dağıtım testi için kullanılır vb. Ek olarak, Python2.7 ve Python3.4, Centos serisi ve Debian serisi gibi çeşitli çevresel uyumluluk testleri vardır.

2. OpenStack fonksiyonel test tasarımı ve uygulaması

Yukarıdakiler, bir taraf olan OpenStack testine kısa bir giriş niteliğindedir. Burada, Keystone, Glance, Cinder, Nova, Neutron ve Swift'in işlevlerini test etmek de dahil olmak üzere OpenStack'in işlevlerini otomatik olarak test etmek için Tempest'i kullanarak bir noktada ayrıntılarına gireceğim.

Tempest'in işlevsel topluluklarının çoğu geliştirilip uygulandığından, kullanıcılar bunları kuruluşun Ar-Ge test ortamında kendi ihtiyaçlarına göre genişletebilir ve kullanabilir. Şu anda Tempest, CI sürekli entegrasyonu, OpenStack topluluğu birlikte çalışabilirlik testi ve sertifikasyonu ve diğer alanlarda yaygın olarak kullanılmaktadır.

1. Docker'da Tempest'i çalıştırın

"İşçiler, başarılı olmak istiyorlarsa önce aletlerini keskinleştirmelidir." Her şeyden önce, Tempest test ortamını kurmanız ve yapılandırmanız gerekir.Docker, her yerde çalışmak için mükemmel hafiflik, çevresel yalıtım ve tek seferlik paketleme özelliklerine sahip olduğundan, Tempest'i bir Docker konteynerine kurmayı ve dağıtmayı seçiyoruz.

Basit bir örnek vermek gerekirse, OpenStack'i A ortamında test ederken, Tempest gibi bir test platformu oluşturmanız gerekir; OpenStack'i B ortamında test ederken, aynı test platformunu; aynı zamanda, farklı ortamların tekrarı nedeniyle oluşturmanız gerekir. Yapılandırma, test ortamının yanlış yapılandırılmasına kolayca yol açabilir. Özetle, çalıştırmak için Docker'ı seçmek daha iyi bir yoldur.

Tempest testinin uygulanması Python'un birim testi2 ve burun çerçevesine dayanmaktadır. Openstack arka ucuna bir dizi API isteği başlatarak ve arka ucun yanıtını doğrulayarak. Tempest, Nova, Keystone, Glance ve Neutron gibi OpenStack ile ilgili hizmetler dahil olmak üzere tüm test ortamını açıklamak için yapılandırma yapılandırma dosyalarını kullanır. JSON ve XML REST API format testinin yanı sıra CLI testini de destekler.

Tempest'in Avantajları

Tempest testleri otomatik olarak bulabilir ve yürütebilir: geçerli dizindeki est ile başlayan tüm Python kaynak dosyalarını otomatik olarak bulur ve bu kurala göre alt dizinleri yinelemeli olarak bulur; est ile başlayan tüm Python kaynak dosyalarında est ile başlayan tüm işlevler ve sınıflar ve Unittest.TestCase'den miras alınan sınıflar (est ile başlamaya gerek yoktur) çalıştırılacaktır.
Tempest, test için dosyaları, modülleri ve işlevleri belirtebilir.
Tempest, test için türü belirleyebilir.
Tempest oldukça genişletilebilirdir, tempest'e başka test senaryoları eklemek uygundur ve stres testleri, senaryo testleri vb. Gibi diğer test türlerini entegre edebilir.
Tempest, python ile yazılmış burun tarafından yönlendirilir ve test araçları ve test kaynakları gibi birkaç test aracı kitaplığı kullanır.
Tempest.test.BaseTestCase, BaseTestCase yapılandırma özniteliğini bildirir ve yapılandırma dosyasını okur
Tempest.test.TestCase, arama için birçok araç işlevini bildirir. Her test JSON formatını ve XML formatını ayrı ayrı test edebilir

Elbette dezavantajı, ağır ve hataya açık olan tempest.conf ortam açıklama dosyasını manuel olarak yapılandırmanız gerekmesidir.

Tempest kodunun ana yapısı aşağıdaki gibidir. Bunların arasında, API'nin test senaryoları ve senaryo bölümleri odak noktamızdır.

tempest /

Test senaryoları ile REST API arasındaki etkileşim süreci aşağıdaki şekilde gösterilmektedir.

1) Docker ve Tempest'i kurun

# yum yükleme penceresi -y

Tempest görüntüsü oluşturmak için bir dockerfile dosyası yazın, içerik aşağıdaki gibidir

# kedi dockerfile

Görüntü oluşturma komutunu yürütün

# docker build -t tempest_docker: 1.0.

Yerleşik resmi görüntüleyin

# docker görüntüleri | grep tempest

Arka planda Tempest yansıtmayı başlatın

# docker run -d -it tempest_docker: 1.0 / bin / bash

Tempest konteynerini çalışırken görüntüleyin

# docker ps | grep tempest

Tempest konteynerine girin ve çalıştırın

# docker exec -u root -it 0a5cf6c1d4b8 bash

2) Yapılandırma dosyası tempest'i kullanmak için, tempest.conf ve accounts.yaml olmak üzere iki dosyayı yapılandırmanız gerekir.

Burada, önce accounts.yaml dosyasını yapılandırın. Bu dosyanın içeriği, Tempest tarafından OpenStack'i test etmek için gereken kiracılar, kullanıcılar ve parolalar gibi kimlik doğrulama bilgilerini içerir. Örnekler aşağıdaki gibidir:

# egrep "^" accounts.yaml

Ardından, tempest.conf dosyasını yapılandırın, burada kısmi test Keystone hizmetinin yapılandırılmasına bir örnek verilmiştir. Hesaplama, Ağ, Hacim vb. Hizmetleri test etmeniz gerekiyorsa, ilgili seçenekleri notlara göre yapılandırın. Örnekler aşağıdaki gibidir.

# egrep "^" etc / tempest.conf

2. Tempest test durumlarını görüntüleyin

Gerçek test ortamında, QA test uzmanları çeşitli test senaryoları yazmaya devam edecek. Kendi geliştirdiğimiz test senaryoları için, test senaryosunun yürütülmesinin türü, adı ve içeriği konusunda doğal olarak çok netiz. Tempest, Rally ve Shaker gibi topluluklardaki otomatik test projeleri için, test senaryolarını nasıl anlarız?

Aşağıda, Tempest projesinin tempest / api dizininde test durumlarını elde etmek için kullanılan bir bash betiği bulunmaktadır.

#! / bin / sh

Yukarıdaki içeriği komut dosyasına yazın ve Tempest dizinine koyun. Komut dosyası çalıştırıldığında, tempestresult dizininde sırasıyla testcaselist.txt ve testcase_total.txt dosyaları çıktı. İlki, her proje hizmetinin test olaylarını tempest / api dizininde depolamak için, ikincisi ise her proje hizmeti için istatistiksel test olaylarının sayısını saklamak için kullanılır. .

Testcase_list.txt dosyasını açın, içeriğin bir kısmı aşağıdaki gibidir:

# cat testcase_list.txt

Testcase_number.txt dosyasını kontrol edin, içerik aşağıdaki gibidir:

# kedi testcase_number.txt

3. Tempest kod hata ayıklama

1. ipdb kitaplığını kurun

# pip ipdb'yi yükle

2. Test programının hatalarını ayıklayın

Bir kullanım senaryosunun yürütülmesinde bir hata varsa, tek adımlı hata ayıklama için kesme noktaları eklemeniz gerekebilir. Hata ayıklama işini tamamlamak için pdb hata ayıklama kitaplığını kullanabilirsiniz, ancak hata ayıklama için ipdb kitaplığını kullanmanızı öneririm. Bu kitaplık daha akıllı ve kullanımı kolaydır. Dezavantajı, Python olmayan bir sistem kitaplığı olmasıdır. , Kullanmak için manuel olarak yüklemeniz gerekir.

Kesme noktası tek adımlı hata ayıklama eklemek istiyorsanız, hata ayıklanan kullanım senaryosunu yürütmek için python -m testtools.run yöntemini kullanmanız gerekir, aksi takdirde kesme noktası girilmeyebilir ve tek adımlı hata ayıklamanın yolu yoktur.Hata ayıklamanın ilk adımı Hata ayıklanmış kullanım senaryosuna kesme noktaları ekleyin (tempest.api.compute.servers.testserversnegative.ServersNegativeTestJSON.testrebootnonexistentserver kullanım durumu örnek olarak kullanılmıştır; burada ipdb, pdb benzerdir).

@ test.attr (tür =)

Bundan sonra, kesme noktası hata ayıklama moduna girmek için bu kullanım durumunu python -m testtools.run ile çalıştırın. Komut aşağıdaki gibidir.

# python -m testtools.run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server

4. Tempest testini çalıştırın

Tempest testini gerçekleştirmek için, testr veya nosetests, ostestr, run_tempest.sh komut dosyalarını ve diğer komutları kullanabilirsiniz, ancak topluluk ostestr komutunu kullanmanızı önerir. İşte testr kullanmanın bir örneği.

Keystone v2 sürümünün test listesi geri dönenlerin yetkilendirilmiş test senaryosunu test etmek için bir örnek. Komut aşağıdaki gibidir:

# testr run tempest.api.identity.v2.test_tenants

Test sonucu bilgisini, test senaryosunun başarıyla yürütüldüğünü ve beklenen amacı karşıladığını gösteren aşağıdaki şekilden doğrudan görebilirsiniz.

Bu tür test sonuçlarına göz atmak, analiz etmek veya kullanım senaryolarını kaydetmenin sakıncalı olduğunu düşünüyorsanız, sonuç dosyasını XML biçiminde sürükleyip göz atmak için Excel'e bırakabilirsiniz.

Test durumu analizi.

# vim tempest / api / kimlik / v2 / test_tenants.py

Bu test senaryosunun ana içeriği, kullanıcının yalnızca aynı kiracı altındaki diğer kullanıcıları görüp göremediğini kontrol etmek, kullanıcı tarafından kullanılan kimlik bilgilerini ve kiracı adını doğrulamak ve son olarak kullanıcının "alt" kullanıcı adlı kiracıda oturum açamadığını kontrol etmektir. Programın yürütme sonucunun beklenen değerle eşleşip eşleşmediğini belirlemek için esas olarak assertEqual, assertRaises ve diğer onaylama yöntemlerini çağırın.

Aşağıdakiler testr testi için bazı ilgili komutlardır

1) Komut yardım bilgilerini görüntülemek için testr kullanın

# testr yardımı

Aşağıdaki komutları çalıştırmadan önce, test ortamını yüklemeniz gerekir.

# source .tox / py27 / bin / activ

Testi doğrudan çalıştırın

testr çalıştırma - paralel

Test bittikten sonra, başarısız kullanım durumlarını kontrol edin ve başarısız kullanım durumlarını yeniden çalıştırın

testr başarısız

Batch, API ve senaryodan oluşan iki test senaryosu seti çalıştırın

# ostestr --regex '(?!. * \) (^ tempest \. (api | senaryo))'

Veya aşağıdaki yöntemi kullanın

# testr çalıştırması

Veya testleri paralel olarak çalıştırın

# testr çalıştırma - paralel

Veya paralel olarak bir dizi test durumu çalıştırın

# / root / tempest / tempest / api testr run --parallel

Tek bir test senaryosu çalıştırın

# testr çalıştırması

OpenStack ortamındaki CPU sayısına göre eşzamanlılığı ayarlayın, örneğin 2'ye ayarlayın.

# testr run --parallel - eşzamanlılık = 2

Test analizi gerçekleştirin

# testr run --analyze-isolation

Test senaryolarını listeleyin

# testr listesi-testleri

Tempest senaryo testi gerçekleştirin

# testr run --parallel tempest.scenario

veya

# ./run_tempest.sh tempest.scenario

Yalnızca başarısız test durumlarını yeniden çalıştır

# testr çalıştırması - başarısız

Daha iyi analiz ve göz atma için, xml dosyasını doğrudan Excel belgesine sürükleyip bırakabiliriz.

2) Test sonuçları

Dört tür Tempest test sonucu vardır: Test Hatası (Hata), Test Başarısız (Başarısız), Atlama (Atlama) ve Başarı (Başarı). Anlamları aşağıdaki gibidir.

Test hatası: Test kodu yürütüldüğünde bir hata olarak anlaşılabilir. Örneğin, test kodunda bir yazdırın ve bir değişken bildirimi içermez. Kurulum'a benzer şekilde, kod bu aşamada başarısız olursa, bir test hatası (Hata) olarak da kabul edilecektir. Konfigürasyon ortamında da bir sorun olabilir.
Test hatası: Test kodunun normal şekilde çalıştığı anlaşılabilir, ancak beklenen test sonucu alınmaz.Örneğin, test kodunda fonksiyon kodu add (1, 2) çağrılır, ancak dönüş sonucu 3 değildir.
Atla: Bir testin görmezden gelinmesi olarak anlaşılabilir. Örneğin, bir kullanım durumu yalnızca CentOS sistemi altında çalıştırılır, bu nedenle diğer sistemler altında atlanacak, yani yok sayılacaktır. Test edilmekte olan hizmette bir hata olması da mümkündür.
Başarı: Test senaryosu başarıyla yürütülür, yani test programı tarafından döndürülen sonuç değeri beklenen amacı karşılar.

5. Geliştirme testi raporu

Test raporlarının analizini ve taranmasını kolaylaştırmak ve testte başarısız olan kullanım durumlarını yakalamak için Tempest API entegrasyonu / fonksiyonel test çıktısının nasıl otomatikleştirileceği, QA test uzmanlarının görevlerinden biridir. Görünüşte bulanık test sonuçlarını mümkün olduğunca görselleştirmemiz ve dijitalleştirmemiz gerekiyor.

Tempest test raporlarının çıktısını otomatikleştirmek için HTMLTestRunner.py modül dosyasını kullanmanız gerekir. İndirme adresi:

Tempest kaynak kodu havuzunun / tempest dizininde olduğu varsayılır. Ardından aşağıdaki adımları uygulayın.

# cd / tempest

HTMLTestRunner.py ve otomatik test programı dosyalarını (örneğin, burada sağlanan tempest_keystone.py kullanım durumu programı) Tempest dizininde birlikte depolayın. kod aşağıdaki gibi gösterilir:

#! / usr / bin / env python

Kod açıklaması aşağıdaki gibidir:

Unittest modülündeki TestLoader sınıfı bir keşif yöntemine sahiptir. Discover (start dir, pattern = 'test * .py', topleveldir = None) gibi bu yöntemi kullanarak, belirtilen dizindeki (startdir) ve alt dizinlerindeki tüm test modüllerini özyinelemeli olarak bulun ve ardından bu test modüllerini TestSuite'e yerleştirin Nesne ve geri dön. TestSuite'e yalnızca modelle eşleşen test dosyaları yüklenecektir.

Bir test dosyasının adı kalıpla eşleşirse, dosyanın loadtests () işlevini içerip içermediğini kontrol eder. Loadtests () işlevi varsa, işlev bu dosyadaki test olaylarını yüklemekten sorumludur; yoksa, loadTestsFromModule () çalıştırılacaktır. , Dosyadaki TestCase sınıfından türetilen test ile başlayan yöntemi bulun.

Test komutunu yürütün:

# python tempest_keystone.py

Test komutunu çalıştırdıktan sonra, / home dizininde HTML formatında bir test raporu oluşturulacaktır.Aşağıdaki şekilde gösterildiği gibi dosyayı açmak için bir tarayıcı kullanın.

Bunun, Tempest'teki kimlik projesinin (Keystone sertifika hizmeti) v2 sürümündeki kullanım durumları için bir test olduğu unutulmamalıdır. Başka proje testleri çalıştırırsanız, bu yönteme başvurabilirsiniz.

Test raporu görünümü

Test sonucu raporu, e-posta ve tarayıcı gibi çeşitli şekillerde görüntülenebilir. Örneğin, test raporunu ilgili personelin e-postasına veya Web sunucusuna otomatik olarak göndermek için bir program geliştirebiliriz, böylece bir URL adresini ziyaret etmek için bir tarayıcı kullandığımızda, test sonuçlarını kolayca görebiliriz. Bu içerik etrafında, kapsamlı bir etki elde etmek için günlük QA testi, CI / CD ve diğer Ar-Ge test bağlantılarına da uygulanabilir.

3. Yapay zeka yapay zekasının yazılım testi üzerindeki etkisi

AlphaGo, insan-makine savaşında Li Shishi'yi 3: 0 mutlak üstünlüğüyle yendiğinden beri, yapay zeka bir karmaşa haline geldi.Eğer bir gecede yapay zeka hakkında konuşmazsanız, yabancı bir gezegenden geliyormuş gibi geliyor. Peki, yapay zekanın yazılım testi üzerindeki etkisi nedir?

Yazılım test teknolojisinin gelişmesinden bu yana, sayfa nesnelerine (POM) dayalı model testinin yapay zekaya daha yakın bir test yöntemi olduğu söylenebilir. Ancak yapay zeka yapay zekasının açıkça bir adım daha ileri gitmesi gerekiyor ve test senaryolarının ve test senaryolarının otomatik olarak oluşturulmasını gerektiriyor. Test uzmanlarının önce yazılım işlevlerine dayalı olarak çeşitli modeller (veya davranışlar olarak adlandırılır) oluşturmasını ve ardından davranış ile davranış arasındaki ilişkiyi ve bir bütün olarak davranış ve sistem arasındaki ilişkiyi formüle etmesini gerektirir ve ardından otomatik test sistemi, test edilen mevcut sistemi akıllıca temel alabilir. Durum (sahne) ve önceden belirlenmiş kurallar, daha sonra yürütülecek davranışı seçin.

Teorik olarak, bu test yöntemi, test edilen sistemdeki çeşitli olası davranış zincirlerini mümkün olduğunca çok geçerek test kapsamını büyük ölçüde geliştirebilir. Yürütme yolu her seferinde sabit olmadığı için tamamen farklı test senaryoları oluşturabilir.Ayrıca buna akıllı yazılım testi de diyebiliriz.

Model tabanlı yapay zeka testi, her şeyden önce çeşitli OpenStack işlemlerini model olarak tanımlamaktır. Burada sanal makinenin çeşitli işlemlerinden örnekler alıyoruz. Genel olarak, bir sanal makinenin birden çok durumu vardır, örneğin çalıştırma, askıya alma, yeniden başlatma, geçiş, anlık görüntü vb. Şu anda, durum ve durum arasında bazı standart işlemler tanımlayabiliriz. Bu durumları ve işlemleri çizdikten sonra sanal makinenin (veya sanal makine sahnesinin) durum geçiş diyagramını alabiliriz. Aşağıda gösterildiği gibi.

Gördüğünüz gibi, yukarıdaki şekilde Çalışıyor ve Durduruldu durumu, durdurma ve başlatma işlemleri aracılığıyla bir durum döngüsüne dönüştürülebilir. Daha sonra akıllı test, sanal makinenin önceden belirlenmiş kurallara göre bu halkada sınırlı test yapmasına izin verebilir. Bu çok basit görünüyor, ancak OpenStack'teki diğer kaynakların birçok durum geçiş diyagramı olduğunu ve birçok kaynak arasında karşılıklı bağımlılıklar olduğunu bilmelisiniz.Örneğin, diğer hizmetlerin çalıştığı ve kullanılabilir olduğu varsayımı altında, çeşitli sanal makineler İşlem sorunsuz yürütülecektir. Ayrıca, kullanıcılar OpenStack'i çalıştırdıklarında, yalnızca sanal makinenin durumunu değiştirmezler ve genellikle işlemleri diğer kaynakların davranışlarıyla karıştırırlar. Bu nedenle, tüm kaynakların geçişini bitirdiğinizde, tüm OpenStack sahnesi ile isteğe bağlı davranış arasındaki ilişkinin çok karmaşık olduğunu göreceksiniz.

Son olarak, test senaryoları ile tempest.conf yapılandırma dosyası arasındaki ilişki ve Tempest test durumlarının kendi ihtiyaçlarına göre nasıl genişletileceği gibi Tempest hakkında incelenebilecek birçok hikaye noktası ve içerik vardır. Bu paylaşım içeriği şu anda satışta olan "OpenStack Best Practices-Testing and CI / CD" kitabının 5.5.1 bölümünden derlenmiştir.

soru Zamanı

Örneğin bir sanal makine oluştururken bir hata var yani ana işletim sisteminde kirli veriler olabilir ve aynı zamanda DB'de de olabilir Bu şeyler nasıl temizlenir? Veya çevrenin temiz olmasını nasıl sağlayacağınızı. Özellikle hortumlarda temiz mi?

Örnek olarak Tempest'i alın: Bir VM oluşturduktan sonra, istisna veya hata (veya bir program hatası) yoksa, tempest, VM'yi ve ilgili kaynakları otomatik olarak silecektir.

Şu anda geliştirme için hangi araçları kullanıyorsunuz? Hata ayıklama nasıl yapılır? Test kısmını sadece şimdi gördüm, teşekkürler!

Her geliştirici farklı araçlar kullanır.Örneğin, kod görüntüleme için eclipse + pydev ve hata ayıklama için ipdb kullanacağım.

Değiştirilen kodunuz topluluğa gönderilecek mi? Bazı kısımlar topluluğa sunulamazsa, bunu nasıl sürdürüyorsunuz? Bir sonraki OpenStack sürümü nasıl birleştirilecek? Teşekkür ederim! Sürüm nasıl kontrol edilir?

Yazılım projeleri için, birleşik yönetim için genellikle sürekli entegrasyon Jenkins kullanırız Daha güncel DB veri alanlarına sahip işletmeler için başka iyileştirmeler gerekebilir.

Güvenlik testi nasıl yapılır?

Güvenlik testi için, herkes veya her ekip, ortak SQL enjeksiyonu, sızma ve ön uç sayfaların güvenlik açığı taraması gibi buna farklı şekilde odaklanır.

Openstack depolama performansı için daha iyi test yöntemleri bilmek ister misiniz?

Openstack depolama performansının testi için, "OpenStack En İyi Uygulamalar-Test ve CI / CD" bölüm 5.6'ya bakın. Örneğin, openstack + ceph entegrasyonu durumunda, aşağıdan yukarıya, sunucuların kendileri vardır ve ayrıca Ceph kümeleri vardır, RBD blok depolama, sanal makineler vb.

Her bileşenin test edilmesine yönelik kullanım senaryoları, her bileşenin işlevlerinin çoğunu kapsamalıdır, değil mi? Bu işlevler önce bileşen yapılandırma dosyasında yapılandırılmalıdır, değil mi?

tempest, önceden tempest.conf dosyasında yapılandırılması gereken genel projelerin API işlev testini destekler. Şu anda nispeten önemsizdir.

Sabit bir hatamız varsa, çeşitli nedenlerden dolayı topluluğa giremiyoruz ancak ürünümüzde doğrulamayı geçtik ve ürüne gireceğiz.Sürüm kontrolü için dahili olarak gitlab kullanıyoruz

Test raporu, akıllı analizler yapabilir ve test verilerine dayalı optimizasyon önerileri verebilir mi?

İyi bir test raporu, akıllı analizler yapmalı ve test verilerine dayalı optimizasyon önerileri vermelidir Testin amacı hataları bulmak ve kontrol etmektir.

Farklı üreticilere ve modellere ait 200 eski PC sunucum var Test veya iş kullanımı için büyük bir küme oluşturmak için işletim sistemini kullanırsam, bu uygulanabilir mi? Genel plan hakkında konuşur musunuz?

Bir OpenStack test ortamı oluşturmak için yeterli olması gereken farklı üreticilerin ve modellerin 200 eski PC sunucusuna sahibim (özel gereksinimler yok), ancak bir üretim sistemi kullanılması tavsiye edilmiyor. Kaynak ortamı için kendi izolasyon gereksinimlerinize bağlı olarak kullanılmayan bir işletim sistemi ortamı geliştirebilir, test edebilir ve kullanabilirsiniz.

OpenStack için minimum donanım gereksinimleri nelerdir?

OpenStack minimum donanım konfigürasyon gereksinimlerine sahiptir.İkinci yılımda, dizüstü bilgisayarımda sanal bir makinede (2 Çekirdek, 4 GB bellek) hepsi bir arada bir OpenStack kurduğum söylenebilir.Ayrıca başarıyla dağıtılabilir, ancak temelde Kullanım yok

Yazar, üretimde afet toleransını nasıl yapıyor? Şu anda bulutun odak noktası, felaket kurtarma ve bulut güvenliği konusunda daha fazla endişeye sahip

Üretim ortamında bulut felaket kurtarma için bu ortak bir konudur ve farklı gereksinimlerin farklı özel uygulama çözümleri olabilir. Örneğin, ceph depolarsa, daha fazla MON ve daha fazla OSD olacaktır. OpenStack hizmetinin HA'sı Haproxy, tutulan, vb. İçerebilir. Ancak şahsen etkili ve zamanında izleme, çalıştırma ve bakım ile erken uyarının daha önemli olabileceğini düşünüyorum.