“OpenStack Platform”unu compute, storage ve network kaynaklarını kontrol edebilmek için birbiriyle etkileşim içerisinde olan servislerin bir bütün halinde implementasyonu olarak tanımlayabiliriz.  Openstack’in çekirdek (“core”) servislerini aşağıda verilen Şekil 1.1 ile resmedebiliriz.

Şekil 1.1. OpenStack Mimarisi

OpenStack Servisleri

OpenStack servislerini kısaca anlamaya çalışalım. Birinci servisimiz Horizon diğer ismiyle “dashboard”dur. OpenStack servislerini yönetmek için kullanılan web tabanli bir arayüzdür. Bu grafiksel kullanıcı arabirimi erişimlerin tanımlanması, network servislerin yönetilmesi, oluşturduğunuz “instance” ların başlatılması gibi pek çok operasyonel işlemleri yapmanıza imkan sağlar. İkinci servisimiz Keystone diğer ismiyle “identity” dir.  Keystone, kullanıcı ve bileşenler için Single Sign-On doğrulama servisi sağlar. Bu servis, kullanıcıların, rollerin, projelerin (OpeStack’in eski sürümlerinde tenant olarakta geçmektedir)  oluşturulması ve yönetilmesinden sorumludur. Farklı formlardaki doğrulama mekanizmalarını destekler.  Standart kullanıcı ismi ve şifreleme mekanizması, token tabanlı sistemler, Amazon Web services (AWS) loginleri bu desteklenen yöntemler arasında sıralanabilir. Üçüncü servisimiz Neutron diğer adıyla “network” tür.  Neutron, softeware tabanlı network servisidir.  Network’lerin, subnet’lerin, router’ların ve kayan/hareket eden (“floating”) IP’lerin  oluşturulması için kullanılır.  OpenStack networking, plug-in ve ajanlarla birlikte gelir. Ajanlar, Cisco virtual ve fizksel switch’leri, Open vSwitch’leri ve daha pek çok teknolojiyi kapsar.  En yaygın ajanlar L3 ve DHCP’dir. OpenStack networking, projelerin gelişmiş sanal network topolojileri oluşturmasına imkan sağlar. Örneğin firewall, load balancer ve virtual private network (VPNs) gibi. Dördüncü servisimiz Cinder diğer adıyla “block storage”dır.  Cinder servisi,  sanal makineler için “storage volume” leri yönetir. Bu, “Nova” içinde çalışan “instance”lar için kalıcı “block storage” yapısıdır. Veri yedeklerini almak için “snapshot” lar alınabilir. Özellikle veritabanı dosyaları için kullanılır.  Beşinci servisimiz Nova, diğer adıyla “compute”dür. Bu servis, “node”lar üzerinde çalışan sanal makineleri yönetir, istek üzerine yeni sanal makineler sağlar. Nova, dağıtık bir servisdir. Yani, doğrulama (“authentication”) için Keystone ile etkileşim halindedir. İmajlar için Glance ile etkileşim halindedir. Web arabirimi için de Horizon ile etkileşim içindedir. Nova, standart donanım üzerinde yatay olarak büyüyecek şekilde dizayn edilmiştir.  Altıncı servisimiz Glance diğer adıyla “image”dır.  Glance servisi, sanal makine imajları için “register” gibi hareket eder. Bu imajlar, yeni “instance” lar oluştururken şablon olarak kullanılabilir.

Aslında toplamda 16 tane servis var (en azından şimdilik. J) . Bu nedenle bu yazımda hepsinden bahsetmek istiyorum. Umarım sıkıcı olmaz.  Yedinci servisimiz Swift diğer adıyla “object storage”dır. Bu servis nesne tabanlı depolama birimi sağlar. Swift mimarisi dağıtık yapıdadır ve yatay olarak büyür ve dizaynı hataları tolere edecek şekilde yapılmıştır. Sekizinci servisimiz  Heat diğer adıyla “orchestration”dır.  Birden fazla cloud uygulamasını yönetmek için kullanılan bir servistir. Bu amaç ile Amazon Web Services (AWS) CloudFormation şablon formatını kullanır. Bu şablon formatını REST API (“Representational State Transfer”) ve CloudFormation-compatible Query API üzerinden yapar. Dokuzuncu servisimiz Ceilometer diğer adıyla “telemetry”dir.  OpenStack Telemetry servisi kullanıcı seviyesinde kullanım datasını sağlar. Bu veriler, müşteri faturalarını oluşturmak, sistemi monitör etmek veya alert üretmek için kullanılır. OpenStack servisleri tarafından gönderilen notifikasyonları toplayabilir.  Bu servis ek olarak plug-in lerde sağlar. Bu plug-in lerle yeni monitör metrikleri eklenebilir. Onuncu servisimiz Gnocchi diğer ismiyle “time series database”  (TDBaaS) dir. Ceilometer tarafından toplanan kaynaklar için metrikleri depolar. Bu veritabanı depolama için “Swift”i kullanır.  Onbirinci servisimiz  Trove diğer ismiyle “relational database”dir.  Trove, Database as a Service (DBaaS) olarak tanımlanır. Buradaki amaç, ölçeklenebilir ve güvenilir ilişkisel database “engine”ler sağlamaktır.  Bu servis, yüksek performans için izolasyon sağlar. Örneğin karmaşık veritabanı yönetimsel işlemleri otomotize ederken faydalar sağlar. Onikinci servisimiz Manila diğer ismiyle “shared file storage”dır. Manila, “Secure file as a service” olarak tanımlanır. Dosyaları paylaşırken NFS ve CIFS protokollerini kullanır.  Single-node back-end olarak konfigüre edilebileceği gibi birden fazla node üzerinde çalışacak şekilde de konfigüre edilebilir.  Onüçüncü servisimizin ismi Sahara diğer ismiyle “data processing”dir.  Sahara, OpenStack üzerinde Hadoop, Spark, Storm gibi data processing yapılarını kullanmak için kullanıcılara kolaylık sağlar. Ondördüncü servisimiz TripleO’dur. TripleO, diğer adıyla OpenStack on OpenStack (OOO), OpenStack’in kendi servislerini temel alarak OpenStack cloud yapılarının kurulması, güncellenmesi ve işletilmesi amaçlı geliştirilmiştir.  Onbeşinci servisimiz Ironic diğer adıyla “bare-metal provisioning”dir.  Ironic, OpenStack’in bir projesidir. Sanal makineleri hazırlamak yerine fiziksel donanımları hazırlamaya odaklanmıştır. PXE, IPMI gibi sürücüler sağlar. Aynı zamanda üretici firmaya spesifik sürücülerin eklenmesini de sağlar. Son servisimiz, yani onaltınce servisimiz Tempest diğer adıyla “Integration testing” dir. Bu servis sayesinde, OpenStack deployment’larını doğrulayabilirsiniz. OpenStack API’lerini, senaryoları  doğrulamak için testler içerir.

OpenStack Terminolojisi

Bu bölümde OpenStack yapısında kullanılan kavramları aktarmaya çalışacağım.

  • “Cloud Controller”: Koordinasyonu sağlayan birimdir. OpenStack cloud içerisinde yer alan tüm sistemler “Cloud Controller” ile iletişim halindedir. Bu iletişim için AMQP (“Advanced Message Queuing Protocol”) kullanılır. Red Hat OpenStack Platform’un AMQP için iki opsiyonu vardır: Apache Qpid messaging daemon (qpidd) ve RabbitMQ.
  • “Cloud” modelleri: Sunulan servise göre cloud servisleri üç model altında kategorize edilebilir: IaaS (Infrastructure as a Service), PaaS (Platform as a Service) ve SaaS (Software as a Service). Red Hat OpenStack Platform’u IaaS tabanlıdır. Yani firmalar altyapılarını bu ürün ile inşa edebilirler. Diğer taraftan Red Hat OpenShift ise PaaS yapısı sağlar. Bu sayede uygulamalar için ölçeklenebilir bir platform sağlar.
  • “Compute Node”: Hipervizör katmanıdır. Nova compute servisini çalıştıran herhangi bir sunucu olabilir.
  • “Volume (Block Storage)”: Tek bir “instance” a eklenen kalıcı disktir. “Volume” ler kalıcıdır ve çalışan “instance” lardan çıkarılabilir veya “instance”lara eklenebilir. Cinder servisi, back end olarak default konfigürasyonda LVM kullanır. “Volume” ler “instance”lara “raw device” olarak sağlanır. Mantıksal  “volume”ler bu “volume group” üzerinden oluşturulur. Normal mantıksal “volume”lerde olduğu gibi “volume snapshot” ları oluşturulabilir.
  • “Ephemeral Disk”: “Instance” tarafından kullanılan geçici disktir. “Instance” oluşturulduğu zaman “ephemeral disk”, QCOW2 imajı olarak “compute node” üzerinde /var/lib/nova/instances/instance-00000000X/disk.local dizini içerisinde oluşturulur.
  • “Instance”: Sanal makinedir.
  • “Flavor”: “Instance” ile ilişkilendirilen donanımdır. RAM, CPU, disk gibi.
  • “Stack”: Şablondan oluşturulan “instance” grubudur. Şablon dosyaları JSON (“JavaScript Object Notation”) formatında yazılır.  “Stack” ve şablon dosyaları, “Heat” orkestrasyon servisi içerisinde kullanılır.
  • OpenStack Networking (Neutron): OpenStack’in networking API’sidir. Network kaynaklarını tanımlarken aşağıda olan kavramları kullanır.
    • Network: İzole edilmiş L2 segmentidir. Fiziksel Network dünyasındaki VLAN ile analojisi kurulabilir.
    • Subnet: IPv4 veya IPv6 IP adresleridir.
  • Open vSwitch: “Virtual Switch” sağlayan yazılımdır. OpenStack içerisinde Open vSwitch plug-in kullanılır. “Traffic queuing”, “shaping” ve otomatik “flow control” sağlar.

OpenStack’den bahsetmişken  “Cloud Computing” den bahsetmeden olmaz. “Cloud” ile ilgili yazdığım diğer yazılar için aşağıda olan linkleri inceleyebilirsiniz.

https://www.linkedin.com/pulse/sanalla%C5%9Ft%C4%B1rma-virtualization-ve-bulut-cloud-temel-kavramlar%C4%B1-yigit?trk=mp-author-card

https://www.linkedin.com/pulse/oracle-private-cloud-appliance-pca-asiye-yigit?trk=mp-author-card

https://www.linkedin.com/pulse/oracle-bulut-%C3%A7%C3%B6z%C3%BCm%C3%BC-cloud-platform-solution-asiye-yigit?trk=mp-author-card

Cloud Computing

“Cloud computing” i çok genel olarak konfigüre edilebilir kaynaklardan (örneğin network, server, storage, uygulamalar, servisler gibi) oluşan paylaşımlı bir havuzun istek üzerine network üzerinden erişilebilir hale getirilmesini tanımlayan bir model olarak düşünebiliriz.  Servis sağlayıcı ile  minimum etkileşimle veya minimum yönetim eforu ile hızlıca istenen yapıların oluşturulabileceği bir platformu tanımlar. Kullanıcı istediği kadar sanal makineyi başlatabilir. “Cloud computing”, birkaç önemli karakteristik içerir.

  • Self-service: “Cloud Consumer” ın “instance”lar (sanal sistemler) oluşturmasına imkan sağlar.
  • Multitenancy: Birden fazla “cloud consumer” in ilgili donanımı paylaşmasına olanak sağlar.
  • Elasticity: İstekleri karşılayabilmek için büyüyebilmelidir (scale out veya scale in).
  • Telemetry: Kaynaklar gerek servis sağlayıcı gerekse “cloud consumer” tarafından monitör edilebilmeli, ölçülebilmelidir.

“Cloud workload” ile geleneksel “workload” u karşılaştıracak olursak neler söyleyebiliriz birazdan bu konunun üzerinde duralım. Geleneksel iş yüklerinde, bir tane makine iş yükünü karşılamak için yapılandırılır. İş yükü arttığı zaman makine, scale up,  şeklinde büyür. Yani makineye daha fazla RAM, CPU, depolama birimi eklenir.  Şekil 1.2 bu mimariyi resmetmektedir. Geleneksel iş yükleri client-server mimarisini kullanır. “failover” ve “scaling”, altyapı üzerinde yapılandırılır.

Şekil 1.2. Geleneksel iş yükü

“Cloud” iş yüklerinde ise uygulama dizaynında değişiklikler gerekir. Uygulama, dağıtık bir mimariyi kullanır.  “Failover” ve “scaling”, uygulama üzerinde yapılandırılır.  Uygulama, ihtiyacı karşılamak için eklenen  daha fazla sanal “instance” ile scale out olarak büyür.  Şekil 1.3 bu mimariyi resmetmektedir.

Bu yazımda genel anlamda OpenStack’den bahsetmek istedim. Umarım faydalı bilgiler sunabilmişimdir. Sorularınız olursa support@gantek.com adresine e-posta gönderebilirsiniz.

Asiye Yiğit

18 Ekim 2016 – Salı