ONAP ile Servis Oluşturma

Emin Aktaş
9 min readFeb 5, 2021

--

Merhaba, bu yazımda sizlere ONAP ile kendinize ait servis oluşturulmasından ve bu işlemleri REST API’ler üzerinden nasıl yapabileceğinizi göstereceğim.

Kısaca ONAP nedir dedikten sonra kurulu ONAP ortamında ufak bir kaç değişiklik yapıp, adım adım iki sanal ağ işlevleri (VNF — Virtual Network Function) oluşturulması gerçekleştireceğiz.

Kısaca ONAP

Open Network Automation Platform (Açık Ağ Otomasyonu Platformu) kısaca ONAP, Linux Fundation tarafından desteklenen açık kaynaklı tam yaşam döngüsü yönetimine sahip bir fiziksel ve sanal ağların düzenleme ve otomatikleştirme platformudur.

OpenECOMP ile Open-Orchestrator projesinin birleşimiyle doğan ve diğer açık kaynaklı projelerinde içerisinde barındığı devasa bir yapıya sahiptir.

Eğer bu konuya çok daha yeniyseniz bağlantıya erişerek ONAP özelinde hazırlanmış ücretsiz derslere erişebilirsiniz. Bu konuyu daha ileriye taşımak isterseniz ücretli dersler ve Certified ONAP Professional (COP) Exam ile ONAP bilginizi bir sertifika ile taçlandırabilirsiniz.

Bu çalışma Frankfurt ve Guilin versiyonlarında test edilmiştir. Burada yer alan bilgiler sonraki versiyonlar için değişiklik gösterebilir.

Servis Oluşturma:

Burada anlatılan adımlar Pre-Onboarding, Onboarding, VF Creation, Service Design ve Service Distribution, daha sonrasında Pre-Service Instantiation ve Service Instantiation adımlarını kapsamaktadır.

Gereksinimler:

Adım — 1: SDC

Service Design and Creation (SDC), modelleme ve tasarım aracıdır. ONAP bileşenleri tarafından kullanılan VNF, PNF (Fiziksel Ağ İşlevi — Physical Network Function) gibi ağ işlevselleri tanımlayan verileri oluşturur.

Bu bileşen içerisinde sırayla VLM(Vendor License Model), VSP(Vendor Software Product) ve Servis oluşturma ve dağıtma adımlarını gerçekleştireceğiz.

Öncelikle, ONAP Portal ara yüzüne erişim sağlayın, ardından SDC seçip, açılan pencerede “ONBOARD” sekmesine geçiş yapın. Bu kısımda bir VLM oluşturup, ardından ayaklandırmak istediğimiz VM’lerin HOT dosyalarını yükleyeceğiz. Bu adımları aşağıda belirttiğim kullanıcı için yetkilendirilmesi varsayılan olarak tanımlı olduğu için bu bilgileri kullanabilirsiniz.

https://portal.api.simpledemo.onap.org:30225/ONAPPORTAL/login.htm
Username: cs0008
Password: demo123456!
ONAP Portal — ONBOARD

VLM

“CREATE NEW VLM” seçtikten sonra karşınıza çıkan ekranda “Vendor Name” ve “Description” bilgilerini ekledikten sonra “CREATE” butonuna tıklayarak VLM oluşturulur.

Yeni açılacak sayfada sırayla “License Key Groups” , “Entitlement Pools” , “Feature Groups” ve “License Agreements” oluşturulup yeni VLM bildirilir.

Tanımlanması gereken kısımları aşağıda belirttiğim gibi kullanabilirsiniz.

Create New License Key Group ->
General ->
* Name: <LKG-isim>
* Type: Universal
Create New Entitlement Pool ->
General ->
* Name: <EP-isim>
* Type: Universal
* Manufacturer Reference Number: <EP-referans numarası>
Create New Feature Group ->
General ->
* Name: <FG-isim>
* Part Number: <FG-parça-numarası>
Entitlement Pools ->
Available EP altında eklediğiniz EP ismini seçerek Selected EP altına taşıyın.
License Key Groups ->
Available LKG altında eklediğiniz LKG ismini seçerek Selected LKG altına taşıyın.
Create New License Agreement ->
General ->
* Name: <LA-isim>
* License Term: Unlimited
Feature Groups ->
Available FG altında eklediğiniz FG ismini seçerek Selected FG altına taşıyın.

Bu işlemler tanımladıktan sonra “Overview” sekmesine geçiş yaparak, yaptığınız işlemleri Connections List altında görebilirsiniz. Ardından “Submit” seçeneğine tıklayarak VLM işlemi tamamlanır.

VSP

Servis oluşturmak için kullanacağımız VNF parametrelerinin yer aldığı HOT dosyalarını yüklenmesini ve az önce oluşturduğumuz VLM ile bu VSP’yi lisanslayacağız.

“CREATE NEW VSP” tıkladıktan sonra “Name”, “Description”, “Vendor”, “Category” bilgileri belirtilip ve “ONBOARDING PROCEDURE” altında “Network Package” seçildikten sonra “CREATE” butonuna tıklayarak VSP oluşturulur.

Bizi yeni karşılayacak ekranda “License Agreement” Missing olarak göreceksiniz. Buraya tıklayarak “LICENSES” altından “Licensing Version”, “License Agreement” ve “Feature Group” seçilerek, “Overview” sekmesine geri dönülür.

GitHub Reposundan indirdiğiniz HOT dosyalarını burada kullanacağız. “SELECT FILE” tıklayarak herhangi bir tane zip dosyalarından birisi eklenir (sırası önemli değil fakat base ve basic ayrıştırmanız gerekir.) ve bu işlem sonucunda bizi onaylama sayfasına yönlendirecektir. Burada “PROCEED TO VALIDATION” tıklanır, sunduğumuz HOT dosyasında hata kontrolü yapılır. Burada karşınıza hata çıkmayacaktır. “Submit” edilerek ilk VSP oluşturma işlemi tanımlanır.

Diğer zip dosyası içinde aynı işlem gerçekleştirilir.

Bundan sonraki işlemleri “SDC” → “HOME” altında gerçekleştirecektir. “ONBOARD” yanındaki ok sekmesine tıklanarak “HOME” sayfasına geçiş yapılabilir.

VSP’ler oluşturulduktan sonra VF (Sanal İşlev — Virtual Function) olarak import edilmesi işlemi gerçekleştirilip, arından servis oluşturacağız.

“HOME” sayfasında “IMPORT” üzerine imleç getirilir ve “IMPORT VSP” seçilir. Burada oluşturduğunuz VSP isimlerinin sol kısmındaki “>” işaretine tıklayarak “IMPORT VSP” seçeneğine tıklanır açılan sayfada “Create” seçeneğine ardından “Certify” seçeneğine tıklanarak VF’ler oluşturulur. Bu işlem diğer VSP içinde tekrarlanır.

Servis oluşturma adımına geçiş yapabiliriz. “ADD” üzerine imleç getirilir ve “ADD SERVICE” seçeneğine tıklanır. Açılan sayfada aşağıdaki belirtilen bilgiler doldurulduktan sonra “Create” ile servis oluşturulur.

* Name: <servis-ismi>
* Cetegory: Network L4+
* Description: <açıklama-belirt>
Composition

“Composition” menüsü altında oluşturacağımız servis için VF’ler sürüklenerek tasarım alanına eklenir. VF’leri bulmak için sol menü üzerindeki arama kutucuğuyla yada Network L4+ sekmesi altından kolay bulunabilir.

Burada oluşturulan servis için farklı bir ayar yapılması gerekmediği için “Certify” seçeneğine tıklanıp onaylanması ardından “Distribute” edilir. Fakat istenilirse “Certify” işleminden önce “Properties Assigment” altında “.env” dosyaları ile sağadığımız bilgiler değiştirilebilir.

“Distribution” menüsü altında takibi sağlanabilir. Ekran görüntüsünde gibi olduğunda işlem tamamlanmış demektir. Bundan sonraki adımlar ise POSTMAN üzerinden gerçekleştirilmeye devam edeceğiz.

# so-catalog-db-adapter servisin değiştirilmesi için
$ kubectl edit svc -n onap $(kubectl get svc -n onap | grep so-catalog-db-adapter | awk '{print $1}')
# so-request-db-adapter servisin değiştirilmesi için
$ kubectl edit svc -n onap $(kubectl get svc -n onap | grep so-request-db-adapter | awk '{print $1}')

Aşağıdaki ekran görüntüsündeki gibi gelen kısımda ClusterIP → NodePort olarak yazılması yeterlidir.

ClusterIP (Önce)
NodePort (Sonra)

Böylece aşağıdaki kodlar ile yeni port numarası bilgileri elde edilmiş olur. Bu port bilgilerini eklemiş olduğunuz POSTMAN enviroment içerisinde tanımlanması gerekmektedir. Böylece, POSTMAN üzerinde API istekleri istediğimiz yere ulaşmasını sağlamış oluruz.

# so-catalog-db-adapter servisin yeni port numarası 31257
$ kubectl get svc -n onap | grep so-catalog-db-adapter
# so-request-db-adapter servisin yeni port numarası 30607
$ kubectl get svc -n onap | grep so-request-db-adapter

k8s, so-db-catalog, so-request-db-adapter, tenant-id, tenant-name, cloud-owner ve region-id parametreleri için hedef ONAP ortamına göre girdiğinizden mutlaka emin olun.

# POSTMAN Enviroment
# Oluşturulacak servis örneği adı Ör: test-custom-svc-1
instance-name: <instance-name>
# Servis oluşturulması adımında belirtilen isim
service-model: <service-model>
k8s: <k8s-ip>
so-db-catalog: <so-db-catalog-port>
so-request-db-adapter: <so-request-db-adapter-port>
tenant-name: <tenant-name|Default:Onap>
cloud-owner: <cloud-owner|Default:CloudOwner>
region-id: <region-id|Default:RegionOne>
# OpenStack tenant ID bilgisi
tenant-id: <tenant-id>
# https://www.345tool.com/generator/random-id-generator bağlantıdan id üretilebilir. Ör: c622e879-5a56-4895-aa54-16a28ce937c5
owning-entity-id: <owning-entity-id>
# Diğer bilgiler istenildiği gibi belirtilebilir
owning-entity-name: <owning-entity-name>
platform-name: <platform-name>
lob-name: <lob-name>
project-name: <project-name>
global-customer-id: <global-customer-id>
subscriber-name: <subscriber-name>

POSTMAN

Buradaki adımlar Collection altında iki farklı klasöre bölünerek yapılmıştır. Servis ayaklandırılmadan önce, servis için gerekli parametrelerin tanımlanmasının yapıldığı “Pre Service instantiation Operations” ve servis ayaklandırma işlemleri “Service Deployment” altında toplanmıştır.

Pre Service instantiation Operations

Servis için kullanılacak owningEntity, lineOfBusiness, Platform, Project ve Customer bilgilerin oluşturulması POSTMAN aracılığı ile POSTMAN Collectionlar ile gerçekleştirilir.
Not: Hali hazırda oluşan veya oluşturmuş olduğunuz bilgileri kullanılması durumunda bu adımları atlayabilirsiniz. Eklenen POSTMAN değişkenlerde owningEntity, lineOfBusiness, Platform, Project ve Customer bilgilerinin hali hazırda oluşturulmuş değerlerle değiştirilmesi gerekir.

“#1 SDC Catalog Service” bu istek ile SDC ara yüz üzerinde oluşturulan tüm servis bilgilerin toplanması sağlanır. Ayaklandırılması istenilen servisin adının bir önceki adımda tanımlanması sayesinde otomatik olarak o servis bilgileri POSTMAN değişkenlerine eklenir. Böylece, Kullanılacak servisin “uuid” bilgisi ile adım 9'da servis’in customer ile ilişkilendirilmesi sağlanır.

“#2 Add Owning Entity” POSTMAN değişkenlerinde tanımlanan OE bilgisinin oluşturulması sağlanır. Burada, “owning-entity-id” aynı formatta olan rastgele bir değer olabilir.

“#3 AAI Owning Entities” GET isteğiyle oluşturulan OE bilgisi görülür.

“#4 Declare the Owning Entity in VID”

“#5 Declare Platform in VID”

“#6 Declare Line of Business in VID”

“#7 Declare Project in VID”

“#8 Add Customer Name”

“#9 AAI Customers”

“#10 Associate Service Model to Customer”

“#11 Associate Cloud Site to Customer”

“#12 AAI cloud-regions/tenant All”

12. adımın tamamlanmasıyla birlikte Servis için gerekecek tüm bilgiler tanımlanmış olur. VID ara yüzünden “Search for Existing Service Instances” menüsü altında aşağıdaki ekran görüntüsünde gibi kontrol edildiğinde “<subscriber-name>” adında subscriber eklendiği görülür. Daha servis oluşturulmadığı için “<subscriber-name>” seçilip “Submit” seçeneğine tıklanırsa hata mesajı döner.

# VID ara yüzüme erişim için
https://portal.api.simpledemo.onap.org:30225/ONAPPORTAL/login.htm
Username: demo
Password: demo123456!

Service Deployment

Servis ayaklandırılma işlemleri aşağıda listelenen API istekleriyle gerçekleştirilir.

“#1 SDC Catalog Service” bu istek ile SDC ara yüz üzerinde oluşturulan tüm servis bilgilerin toplanması sağlanır. Ayaklandırılması istenilen servisin adının bir önceki adımda tanımlanması sayesinde otomatik olarak o servis bilgileri POSTMAN değişkenlerine eklenir.

“#2 — SO Catalog DB Service VNFs for two VM” bu adımdan sonra kullanılacak API istekleri oluşturulan servise özgü olarak hazırlandılar. Oluşturulacak servis için gerekli bilgilerin toplanıp, POSTMAN değişkenlere eklenmesi otomatik olarak gerçekleştirilir. Bu değişkenler sonraki adımlarda kullanılır.

“#3 — SO Request to instantiate Service object” buradaki adım sonrasında “<subscriber-name>” subscriber altında “<instance-name>” adında bir servis oluştuğu görülür. Aşağıdaki ekran görüntülerinde görüldüğü gibi service instance ID’ler uyuşmaktadır.

“#4 — SO Requests Status” arayüze erişmeye gerek kalmadan bu istek ile isteğin başarılı olup olmadığı kontrol edilebilir.

“#5 Request to instantiate VNF object #0” Servis oluşturulması sırasında “Composition” adımında eklenen VF’lerin servis altında doldurulması sağlanır.

VID ara yüzünde kontrolü sağlanırsa aşağıdaki gibi hali hazırda “Add node instance” altında görülürler.

“#6 — SO Requests Status”

“#7 Request to instantiate VNF object #1”

“#8 — SO Requests Status”

VID arayüzünü tekrar kontrol edilirse, VNF lerin oluşturulduğu görülür.

“#9 SDNC Preload #0” bu adımda VNF bilgilerinin OpenStack tarafında ayaklandırılmadan önce SDNC ye Preload edilmesi gerçekleştirilir. Ayrıca, HOT dosyaları içerisinde gönderilen parametreler aşağıdaki örnekteki gibi değiştirilmesi sağlanabilir.

"param": [
{
"name": "vdns_image_name",
"value": "ubuntu-16-04-cloud-amd64"
},
{
"name": "vdns_flavor_name",
"value": "m1.medium"
},
{
"name": "public_net_id",
"value": "public"
},

“#10 SDNC Preload Status” Preload edilen bilgiler bu şekilde kontrol edilebilir.

“#11 SDNC Preload #1”

“#12 SDNC Preload Status”

Şimdi burada dikkat edilmesi gereken bir husus, ekran görüntüsünde “vnf-modelinfo-0..” olarak tanımlanan “CUSTOM-VSP-2” ve “vnf-modelinfo-1..” olarak tanımlanan “CUSTOM-VSP” olduğu görülür. Oluşturulacak bu servis yapısında öncelikli olarak “CUSTOM-VSP” oluşması gerekir. Çünkü, tanımlanan VF ler içerisinde “CUSTOM-VSP-2” kendi ağını oluşturmuyor, “CUSTOM-VSP” oluşturduğu ağlara bağlanıyor. Bu yüzden servislerin ayaklandırılması sırasında yani “#13 instantiate the VF module via SO #0” ve “#15 instantiate the VF module via SO #1” adımları sırasında 15. adıma öncelik verip sonrasında 13. adım gerçekleştirilecek.

“#15 instantiate the VF module via SO #1” SO ya VM oluşturulması için istek gönderilir, eğer herhangi bir hata olmaz ise SO Adapter aracılığıyla istek OpenStack’e doğru gider. Bu adımları ayrıca, konteyner içerisindeki loglar aşağıdaki komutlar ile takibi sağlanabilir.

# Check SO Openstack Adapter Logs:
$ kubectl -n onap get pods | grep so-openstack | grep Running | cut -f1 -d" " | xargs -i kubectl -n onap exec {} -- cat /app/logs/openstack/debug.log
$ kubectl -n onap get pods | grep so-openstack | grep Running | cut -f1 -d" " | xargs -i kubectl -n onap exec {} -- tail -f /app/logs/openstack/debug.log

# Check SO BPMN Logs:
$ kubectl -n onap get pods | grep so-bpmn | grep Running | cut -f1 -d" " | xargs -i kubectl -n onap exec {} -- cat /app/logs/bpmn/debug.log
$ kubectl -n onap get pods | grep so-bpmn | grep Running | cut -f1 -d" " | xargs -i kubectl -n onap exec {} -- tail -f /app/logs/bpmn/debug.log

“#16 — SO Requests Status” İsteğin oluşturulmas sonrasında 16. adımdaki istek ile durumu kontrol edilir. VM in başarıyla oluştuğunun bilgisi görülmektedir.

“#13 instantiate the VF module via SO #0”

“#14 — SO Requests Status”

OpenStack tarafında kontrol edildiğinde, başarılı bir şekilde oluştukları görebilirsiniz.

ONAP ile OpenStack kaynaklarını bu şekilde yönetebilir ve çeşitli hizmetlerini otomatize edebilirsiniz. ONAP sadece API’lar ile değil, Python ve CLI üzerinden servis oluşturma seçenekleride sunmaktadır. Ayrıca, çeşitli otomasyonlar oluşturabileceğiniz CDS modülü ve CLAMP modülü ile scaling, self-healing gibi yeteneklerine sahip servisler oluşturabilirsiniz.

--

--