OpenStack ile Ceph Object Storage Entegrasyonu
Bilindiği gibi Ceph, özellikle bulut iş yükleri için biçilmiş kaftan olup blok depolama, nesne
tabanlı depolama ve dosya sistemi ihtiyaçlarının tamamını bir arada sunan bütünleşik, yeni nesil bir depolama çözümüdür. Tek nokta hatalarına karşı dayanıklı olması, yatay mimaride exabyte seviyelerine kadar kolayca büyüyebilmesi, meydana gelebilecek hataları otomatik düzeltmesi (self healing), açık kaynak kodlu olması ve donanım bağımsız çalışması Ceph’in OpenStack, Proxmox, CloudStack ve benzeri bulut ortamlarında her geçen gün daha fazla kullanılmasını sağlamaktadır.
Açık kaynak kodlu alternatifler içerisinde en çok tercih edilen bulut çözümü olan
OpenStack ise bünyesinde bir çok platform (PaaS) ve uygulama (SaaS) olarak verilen servisler barındırmaktadır. Bu servislerden sadece bir tanesi olan “object storage” servisi, dağıtık yapıda çalışan depolama mimarisine sahip, API üzerinden erişilip kullanılan, verilerin nesneler halinde bir kaç kopya halinde tutulduğu ve geleneksel dosya sistemlerinden farklı olarak içerisindeki nesne sayısı arttıkça performanstan ödün vermeyen hizmet türüdür. Örnek vermek gerekirse Dropbox, Google Drive gibi büyük ölçekli ve çok sayıda dosya barındıran altyapılar “object storage” mimarisinde çalışmaktadır. Dünyada en fazla bilinen “object storage” hizmeti ise Amazon tarafından sağlanan S3 servisidir. Yahoo mühendislik ekibinin 2015 yılında yaptığı duyuruda yaklaşık 250 milyar nesnenin ve 500 peta bayt verinin Ceph Object Storage üzerinden hizmet verdiği ve bu verinin her yıl %20-25 oranında artış gösterdiği belirtilmiştir.
Neden OpenStack ve Ceph?
Genel bir bulut platformu içerisinde blok depolama, nesne depolama ve dosya sistemi tipinde üç tip depolama ihtiyacı bulunur. İşte Ceph, tüm bu ihtiyaçları tek bir ortam üzerinden sağlaması sayesinde diğer çözümlerden her zaman bir adım öne çıkmaktadır.
Benzer şekilde OpenStack üzerinde de, aşağıda listelenen depolama ihtiyaçları ve bunları kullanan servisler bulunmaktadır:
- Ephemeral: Nova ve Glance servisleri tarafından ihtiyaç duyulan ve sanal sunucu ile birlikte oluşturulup sanal sunucu silindiğinde yok olan, genelde işletim sisteminin üzerinde çalıştığı blok depolama alanıdır.
- Block: Cinder servisi tarafından kullanılan ve sanal sunuculara ek disk alanı olarak eklenen blok depolama alanıdır. Sanal sunucu silinse dahi muhafaza edilen ve gerekli hallerde başka bir sanal sunucuya bağlanabilen alanlardır.
- File: Manila servisi tarafından ihtiyaç duyulan ve birden fazla sanal sunucu tarafından eş zamanlı ve paylaşımlı olarak kullanılabilen dosya sistemi tabanlı ortak depolama alanıdır.
- Object: Aslen Swift servisi tarafından kullanılan ve diğerlerinin aksine doğrudan sunuculara bağlanmayan, bunun yerine API üzerinden erişilerek kullanılan nesne tabanlı depolama alanıdır.
Ceph, “ephemeral” ve “block” disk alanlarını Rados Block Device (RBD) arayüzü ile, “shared file system” tipindeki disk alanlarını Ceph File System (CephFS) ile sağlarken “object storage” türündeki ihtiyaçları Ceph Object Gateway (RadosGW) ile sağlamaktadır.
Ceph RadosGW bileşeni, nesne tabanlı depolama hizmetini hem OpenStack Swift hem de Amazon S3 API ile tamamen uyumlu olarak sağlamaktadır. Başka bir deyişle, Ceph nesne tabanlı depolama hizmeti istenirse OpenStack Swift API ile istenirse Amazon S3 API ile kullanılabilmektedir. Bu eşsiz özelliği Ceph’in OpenStack ile entegrasyonunu sağlarken sistem yöneticilerinin de işini kolaylaştırmaktadır. Zira blok depolama için ayrı bir depolama ortamı, paylaşımlı dosya sistemi için ayrı bir depolama ortamı ve nesne tabanlı depolama için farklı bir ortamı kurmak, yönetmek, güncellemek ve idame ettirmek yerine
tek bir depolama çözümü ile tüm ihtiyaçları karşılamak her zaman tercih edilmektedir. OpenStack tarafından bakıldığında sanallaştırma servisleri için eğer bir Ceph çözümü mevcut ise, nesne tabanlı depolama çözümü için ayrıca Swift kurmak ve yönetmek anlamsız olacak ve fazladan iş yükü getirecektir. Yine dağıtık mimaride çalışan Swift için ayrı bir donanım parkı ihtiyacı ortaya çıkacak ve yatırım maliyeti artacaktır. Kaldı ki, Swift servisi tasarımı gereği veriyi tüm replikalara yazmadan önce istemciye yazma işinin yapıldığını bildirmekte, ancak pratikte bu durum veriye erişim sırasında (okuma esnasında) eski bir kopyayı kullanmaya sebep olabilmektedir. Literatürde “eventual consistency” olarak bilinen bu durum Ceph tarafında görülmemekte, verinin tüm kopyaları yazıldıktan sonra istemciye “yazıldı” bilgisi iletilmektedir.
Sayılan bir çok sebepten ötürü uygulamada da Ceph’in tercih edildiği OpenStack Foundation tarafından yapılan anket sonuçlarına da yansımaktadır. OpenStack’i üretim (production) seviyesinde kullananların %48’inin, geliştirme ve PoC amaçlı kullananlar da hesaba katıldığında OpenStack kullanıcılarının %65’inin depolama tercihinin Ceph olduğu açıkça görülmektedir.
Adım Adım OpenStack Ceph RadosGW Entegrasyonu
Bu başlıkta, OpenStack ile Ceph “object storage” servisinin nasıl entegre edileceği adım adım anlatılacaktır. Kullanıma hazır bir OpenStack ve Ceph kümesinin olduğu varsayılmaktadır. Mevcut bir Ceph kümesine “Object Storage” servisinin eklenmesi daha önce yayınlanan bir yazıda alınmıştır.
Entegrasyon tamamlandığında, OpenStack tarafından herhangi bir proje üzerinden Ceph “object storage” servisine ilk kez bir istek geldiğinde Ceph RadosGW kullanıcısının otomatik olarak açılması sağlanmaktadır. Bunun için öncelikle OpenStack tarafında controller sunucu üzerinde aşağıdaki komutlar ile “admin” rolüne sahip bir kullanıcı oluşturulmalıdır. Kullanıcının ismi isteğe bağlı olarak değiştirilebilir.
|
1 2 |
openstack user create ceph --password-prompt openstack role add --user ceph --project admin admin |
İlk komutun ardından sorulan şifreyi iki kez tekrarlamak ve not etmek gerekmektedir. Bu şifre Ceph tarafındaki konfigürasyonda kullanılacaktır.
Ardından aşağıdaki komutlar vasıtasıyla OpenStack için bir “object storage” servisi ve tanımlanmalı ve buna bağlı endpoint adresi olarak Ceph RadosGW erişim adresi verilmelidir. Burada OpenStack üzerinde tanımlı olan region parametresi olması gerektiği gibi düzeltilmelidir. Ceph RadosGW servisinin 443 portunda ve SSL üzerinden çalıştığı varsayılmıştır. Bu parametreler kurulum yapılan ortama göre değiştirilebilmektedir.
|
1 2 3 4 |
openstack service create --region tr-ist-test --name=swift --description="Swift Service" object-store openstack endpoint create --region tr-ist-test swift public "https://tr-ist-test.storage.uyumsoft.com:443/swift/v1" openstack endpoint create --region tr-ist-test swift admin "https://tr-ist-test.storage.uyumsoft.com:443/swift/v1" openstack endpoint create --region tr-ist-test swift internal "https://tr-ist-test.storage.uyumsoft.com:443/swift/v1" |
İşlem sonucu aşağıdaki gibi doğrulanabilir:
Hemen ardından Ceph kümesi üzerindeki monitör sunucularında ilgili RadosGW servisleri için aşağıdaki gibi tanımların eklenmesi gerekir.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
[client.rgw.testmon01] host = testmon01 rgw_frontends = "civetweb port=443s ssl_certificate=/etc/ssl/private/tr-ist-test.storage.uyumsoft.com/tr-ist-test.storage.uyumsoft.com.pem" rgw dns name = tr-ist-test.storage.uyumsoft.com rgw_zone=default rgw_keystone_url = http://testcont:5000 rgw_keystone_admin_user = ceph rgw_keystone_admin_password = {buraya ceph kullanıcı şifresi yazılacak} rgw_keystone_admin_project = admin rgw_keystone_admin_domain = default rgw_keystone_api_version = 3 rgw_keystone_accepted_roles = admin, user rgw_s3_auth_use_keystone = true rgw_keystone_make_new_tenants = true rgw_keystone_verify_ssl = false log file = /var/log/radosgw/client.radosgw.testmon01.log [client.rgw.testmon02] host = testmon02 rgw_frontends = "civetweb port=443s ssl_certificate=/etc/ssl/private/tr-ist-test.storage.uyumsoft.com/tr-ist-test.storage.uyumsoft.com.pem" rgw dns name = tr-ist-test.storage.uyumsoft.com rgw_zone=default rgw_keystone_url = http://testcont:5000 rgw_keystone_admin_user = ceph rgw_keystone_admin_password = {buraya ceph kullanıcı şifresi yazılacak} rgw_keystone_admin_project = admin rgw_keystone_admin_domain = default rgw_keystone_api_version = 3 rgw_keystone_accepted_roles = admin, user rgw_s3_auth_use_keystone = true rgw_keystone_make_new_tenants = true rgw_keystone_verify_ssl = false log file = /var/log/radosgw/client.radosgw.testmon02.log [client.rgw.testmon03] host = testmon03 rgw_frontends = "civetweb port=civetweb port=443s ssl_certificate=/etc/ssl/private/tr-ist-test.storage.uyumsoft.com/tr-ist-test.storage.uyumsoft.com.pem" rgw dns name = tr-ist-test.storage.uyumsoft.com rgw_zone=default rgw_keystone_url = http://testcont:5000 rgw_keystone_admin_user = ceph rgw_keystone_admin_password = {buraya ceph kullanıcı şifresi yazılacak} rgw_keystone_admin_project = admin rgw_keystone_admin_domain = default rgw_keystone_api_version = 3 rgw_keystone_accepted_roles = admin, user rgw_s3_auth_use_keystone = true rgw_keystone_make_new_tenants = true rgw_keystone_verify_ssl = false log file = /var/log/radosgw/client.radosgw.testmon03.log |
Burada sunucu isimleri, sertifika yolu, servisin çalıştığı port gibi bilgiler kurulum yapılan ortama göre düzenlenmelidir. Özellikle dikkat edilmesi gereken parametreler şunlardır:
- rgw_keystone_url: OpenStack kümesine ait keystone servisinin erişim adresi ve portu girilmelidir.
- rgw_keystone_admin_user: Daha önceki adımlarda oluşturulan kullanıcının ismi
- rgw_keystone_admin_password: Oluşturulan kullancıya ait şifre
- rgw_keystone_accepted_roles: OpenStack tarafından istek yapan kullanıcının sahip olması gereken rol (virgül ile ayrılarak birden fazla tanımlanabilir)
Son parametre “rgw_keystone_accepted_roles” OpenStack tarafında kullanılan projeye giriş yapılan kullanıcının sahip olması gereken rolü ifade eder. Eğer kullanıcı burada tanımlanan rollerden birisine sahipse, bu kullanıcıya ait Ceph RadosGW kullanıcısı oluşturulur ve bu kullanıcı “object storage” servisini kullanabilir. Bu sayede OpenStack üzerinde herhangi bir rol tanımlanarak sadece bu role sahip kullanıcıların “object storage” servisini kullanması sağlanabilir. Özetle, yapılan bu entegrasyon sayesinde “object storage” hizmetini kullanması istenen projelere OpenStack üzerinde belirli rolleri tanımlayarak, Ceph kümesinde herhangi bir kullanıcı tanımı yapmadan erişim sağlanmaktadır.
Bu tanımlar eklendikten sonra Ceph RadosGW servisleri yeniden başlatıldığında değişiklikler etkili olacaktır. Örnek komut aşağıdaki gibidir.
|
1 |
systemctl restart ceph-radosgw@rgw.testmon01.service |
OpenStack tarafına Swift servisi ve ilgili endpoint tanımlarının eklenmesi sonrasında web arayüzüne giriş yapıldığında “Object Store” menüsü kendiliğinden aktif hale gelecektir. Menü altında bu projeye ait “container”lar listelenebilir. Dikkat edilirse “object storage” mimarisinde bir dosya hiyerarşisi olmamasına rağmen sanal bir hiyerarşinin “delimiter” kullanımı ile sağlandığı (örneğin huseyin/testhuseyin/Learning_Ceph_Sample.pdf gibi) görülecektir.
Son olarak Ceph RadosGW tarafında oluşturulan kullanılara ait detay bir bilgi vermek faydalı olacaktır. Daha sonra incelemek gerektiğinde kullanıcıları ayırt etmek üzere kullanılması gerekebilir. OpenStack tarafında istek yapan kullanıcıya ait proje uuid bilgisinin, Ceph RadosGW üzerinde kullanıcı oluşturulurken “name” ve “uid” bilgisi olarak kullanıldığı ve bu alanların eşit olduğunu belirtmek isterim.
Ceph Object Storage servisi hem Swift, hem de S3 API desteklediği için belirlenen kullanıcıya ait access ve secret key’ler oluşturularak OpenStack üzerinden Swift API ile erişilen alana S3 ile de erişmek mümkün olmaktadır.