Monthly Archives: December 2015

Ceph Kurulumu

Hizlica ceph kurulumu …

Elimizde son guncellemeleri gecilmis Ubuntu 14.04.3 LTS Trusty isletim sistemi kurulmus linux sunucular mevcut, sunucu listesi ve gorevleri asagidaki gibi belirtilmistir.

  • admin node (10.111.21.184)
  • monitor node 1 (10.111.21.180)
  • monitor node 2 (10.111.21.181)
  • monitor node 3
  • osd node 1 (10.111.21.185)
  • osd node 2 (10.111.21.186)
  • osd node 3

Ilgili release key ekleyelim

root@cephadm:~# wget -q -O- ‘https://download.ceph.com/keys/release.asc’ | sudo apt-key add –

OK

Ceph paketini repoya ekleyelim

root@cephadm:~# echo deb http://download.ceph.com/debian-infernalis/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list

deb http://download.ceph.com/debian-infernalis/ trusty main

Repoyu guncelleyip “ceph-deploy” kuralim

root@cephadm:~# sudo apt-get update && sudo apt-get install ceph-deploy

Kuruluma baslamadan once ;

  • admin node sifresiz diger nodelara girebilmeli cunku tum konfigrasyon islemlerini merkezi olarak yonetecegiz
  • ceph-deploy yine diger nodelarda sifresiz ve sudo hakki olan bir kullanici ile login olmali (uygulama kuracak)
  • “ceph-deploy –username” parametresi ile root dahil yarattiginiz  kullanici adini belirtebilirsiniz
  • ntp tum nodelarda kurulu ve konfigre edilmis olmali, tum nodelar ayni saat degerine sahip olmali
  • openssh-server paketi tum nodelarda kurulu olmali
  • SELinux kapali olmali
  • iptables kurulum engellememsi icin kapali

Ben kurulumumda “root” kullanicisini kullanacagim , onerilmiyor, productionda bu sekilde kullanmayin diyorlar , keza ceph adli bir kullanicida sistemde yaratmayin cunku hackerlar bunu bidiklerinden brute force icin kullanmaya baslasmislar.

SSH Key Yaratalim

root@cephadm:~# ssh-keygen

Dikkat ! “passphrase” bos gecin , sifre atamayin

Key Transfer

Once monitor node 1 icin yapiyorum

root@cephadm:~# ssh-copy-id root@10.111.21.180

The authenticity of host ‘10.111.21.180 (10.111.21.180)’ can’t be established.

ECDSA key fingerprint is 2e:b7:48:94:bb:69:44:ac:3f:c0:e7:f4:8e:a6:17:c0.

Are you sure you want to continue connecting (yes/no)? yes

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys

root@10.111.21.180’s password:

Number of key(s) added: 1

Now try logging into the machine, with:   “ssh ‘root@10.111.21.180′”

and check to make sure that only the key(s) you wanted were added.

Dikkat ! ayni islemi 10.111.21.181,10.111.21.185,10.111.21.186 makinelerindede yapin

Her Node Uzerindeki /etc/hosts dosyasini guncelleyin, benim icin asagidaki ayarlar gecerli , hostname uzerinden birbirlerini pingleyebilmelisiniz

# Ceph MON Nodes

10.111.21.180   cephmon1

10.111.21.181   cephmon2

# Ceph OSD Nodes

10.111.21.185   cephosd1

10.111.21.186   cephosd2

# Ceph Admin Node

10.111.21.184   cephadm

Admin Node uzerinde bir dizin yaratin ve “ceph-deploy” buradan tetikleyin

root@cephadm:~# mkdir cephclusterconfigfiles

root@cephadm:~# cd cephclusterconfigfiles/

Kuruluma baslamadan once oldu ya birsikinti yasadiniz ve tum islemleri sifirlamak istiyorsunuz bu durumda “ceph deploy purgedata nodex nodey” ve “ceph deploy forgetkeys” komutunu kullanin

Ilk ceph baslangic konfig ve keyring dosyasini yaratmak gerekiyor

root@cephadm:~/cephclusterconfigfiles# ceph-deploy –username root new cephmon1

veya (kullanici belirtmek istemezseniz)

root@cephadm:~/cephclusterconfigfiles# ceph-deploy new cephmon1

Iki OSD ile sistemi ayaga kaldiracagiz , onun icin ilgili asagidaki satiri [global] altina ekleyin

osd pool default size = 2

Not : Varsayili deger 3

Kuruluma baslayalim

root@cephadm:~/cephclusterconfigfiles# ceph-deploy install cephmon1 cephmon2 cephosd1 cephosd2 cephadm

Tum ceph binaryleri ilgili nodelara kurulacak

Ilk monitor node’u yaratalim

root@cephadm:~/cephclusterconfigfiles# ceph-deploy mon create-initial

OSD nodelara birer tane 16Gb lik disk ekledim , isletim sistemi bunu /dev/sdb olarak gordu

OSD node ve diskleri hazirlayalim

Asagidaki ornek ikinci node icin , tum node larda bunu yapmalisiniz

root@cephadm:~/cephclusterconfigfiles# ceph-deploy osd prepare cephosd2:/dev/sdb

Bu islemi yaptiginizde goreceksinizki ceph-deploy ilgili node uzerinde guzel guzel partition yaratmis ve onu xfs olarak formatlamis noatime parametresinide vermis olarak.

Asaidaki gibi mount ciktilarina sahip olmus olacaksiniz

/dev/sdb1 on /var/lib/ceph/osd/ceph-2 type xfs (rw,noatime,inode64)

Islemlerde asagidaki gibi “ready” mesaji alip almadiniginiza dikkat edin.

[ceph_deploy.osd][DEBUG ] Host cephosd1 is now ready for osd use.

Simdi OSD leri aktive edelim

root@cephadm:~/cephclusterconfigfiles# ceph-deploy osd activate cephosd2:/dev/sdb1

Burada dikkat /dev/sdb degil /dev/sdb1 olarak verdim aktive ederken

Admin node uzerindeki config sync edelim

root@cephadm:~/cephclusterconfigfiles# ceph-deploy admin cephadm cephmon1 cephosd1 cephosd2

[ceph_deploy.admin][DEBUG ] Pushing admin keys and conf to cephadm

[cephadm][DEBUG ] connected to host: cephadm

[cephadm][DEBUG ] detect platform information from remote host

[cephadm][DEBUG ] detect machine type

[cephadm][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf

[ceph_deploy.admin][DEBUG ] Pushing admin keys and conf to cephmon1

[cephmon1][DEBUG ] connected to host: cephmon1

[cephmon1][DEBUG ] detect platform information from remote host

[cephmon1][DEBUG ] detect machine type

[cephmon1][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf

[ceph_deploy.admin][DEBUG ] Pushing admin keys and conf to cephosd1

[cephosd1][DEBUG ] connected to host: cephosd1

[cephosd1][DEBUG ] detect platform information from remote host

[cephosd1][DEBUG ] detect machine type

[cephosd1][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf

[ceph_deploy.admin][DEBUG ] Pushing admin keys and conf to cephosd2

[cephosd2][DEBUG ] connected to host: cephosd2

[cephosd2][DEBUG ] detect platform information from remote host

[cephosd2][DEBUG ] detect machine type

[cephosd2][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf

ve

root@cephadm:~# ceph health

HEALTH_OK

Bu islemlerden sonra MON ve OSD makinelerinde “ps -fe” yaparak calisan ceph deamon larini gormeye baslayabilirsiniz

ceph      3829     1  0 13:19 ?        00:00:00 /usr/bin/ceph-mon –cluster=ceph -i cephmon1 -f –setuser ceph –setgroup ceph

ceph      1728     1  0 14:38 ?        00:00:01 /usr/bin/ceph-osd –cluster=ceph -i 1 -f –setuser ceph –setgroup ceph

ceph      1694     1  0 14:45 ?        00:00:01 /usr/bin/ceph-osd –cluster=ceph -i 2 -f –setuser ceph –setgroup ceph

Nodelardaki configler “/etc/ceph” altinda bulabilirsiniz

Bu kurulum aslinda komutlarla oynamak icindi , production’da calistirmak icin degil.

Esitliklerle Ceph

ceph = open source distributed storage system

ceph = POSIX uyumlu ve snapshot destekler

ceph genisleyebilir = gigabyte –> exabyte veya x86 tabanli 1000 server’a

ceph’in felsefesi = her bilesen yatayda buyuyebilmeli, asla single point of failure olmamali, software tabanli olmali, herkesin erisebilecegi donanimlar uzerinde olmali, mumkun oldugu kadar kendi kendini yonetebilmeli

tek bir sapka altinda = block , file ve object destekler

gucunu = object tabanli olmadan alir , ona gore block/file/obje hepsi birdir ve bunlari objeler halinde tutar, yedekler , dagitir

2D Ceph = {

Screen Shot 2016-01-13 at 14.36.12

}

Kus Bakisi Ceph = {

Screen Shot 2015-12-29 at 10.36.44

}

Metadata = data hakkinda data 🙂 , her okuma/yazam isteginde neyi nereden okuyacagimiz eger storage kullaniyorsak storage’a ait metadata tablosuna erisip ogreniyoruz demek, bunun icin eski storage tipleri belli bir noktaya kadar genisleyebiliyor . Ufak bir NOT GPFS veya yeni adiyla IBM Spectrum Scale meta data olayini dagitik metadata process’i gelistirerek cozmus  {

Screen Shot 2015-12-29 at 11.02.42

}

CRUSH = Yeni bir “Metadata Lookup” tipi , daha dogrusu artik neyin nereden okunacagi ve yazilacagi  daginik olarak ve isleme tabi tutarak bulunuyor. Bu sayede daha hizli ve exabyte seviyesinde yapilari destekleyebliyor.

CRUSH ayni zamanda = tum ortamdan haberdar bir yapisi var , disk , sunucu , sunucunun bulundugu kabin , kabin’in oldugu datacenter gibi . Oyle ki ilk objeyi yazdiginda yedeginin nereye konacagini hesaplar ki herhangi bir bilesen bozuldugunda datanin problemsiz erisilebilir olmasini saglasin. Olasi bir problemde yine yedek objeyi kullanarak datayi cogaltaraktan yine yedekliligi ust seviyeye cikartir.

ceph = raid yok ,  spare disk yok , illa ayni boyutlarda disklere gerek yok

Erasure Coding = Normalde her bir obje’ni ayni boyutda farkli bir kopyasi yaratilir , erasure coding farkli bir algoritma guderek objeyi daha dusuk maliyetle yedekli olarak tutar.

RBD = Ceph block device access protokolu , bircok linux isletim sisteminde kernel seviyesinde destek var

RBD Destekler = Full/Incremental Snapshot/Thin Provisioning/Copy-on-Write , in-memory caching

RBD Erisim = {

Screen Shot 2015-12-29 at 13.31.57

}

CephFS = Henuz “production ready” degil , kendisi Ceph’in file access bileseni, HDFS (Hadoop) replace olacak gozuyle bakiliyor

Ceph Object Storage =  Ceph halihazirda object based bir storage olup , datayi object olarakda tutabilir.

Ceph Object Gateway (RadosGw) = RADOS gateway client’in RESTFUL API kullanarak sisteme erismesini saglar. Bunlar {

  • Swift Uyumlu
  • S3 Uyumlu
  • Admin API (Yonetim icin)

}

librgw = RADOS gateway , client bu kutuphaneyi kullaniyor

librados = RADOS gateway bu kutuphane ile ceph cluster’a erisiyor

Ceph Object Erisim Diyagrami = {

Screen Shot 2015-12-29 at 13.58.37

}

ceph alternatifleri (tum yonleri ile degil) = {

  • GPFS
  • iRODS
  • HDFS
  • Lustre
  • Gluster

}

Buyuk Resme Baktigimizda = {

Screen Shot 2015-12-29 at 14.48.03

RADOS (Reliable Autonomic Distributed Object Store) = Ceph in kalbi , turune bakilmaksizin , tum erisim methodlari ile gelen (block,file,object) verinin saklanmasi , yedeklenmesi , tutarli olmasi , tutarli olmasi icin yapilmasi gereken ne var ise bu katman bu deamon tarafindan yapiliyor.

OSD (Object Storage Device) = Ceph cluster sisteminde veri OSD denilen parcalara yaziliyor veya buradan okunuyor. OSD bizim icin disk veya disk parcacigi anlaminda ve bu disk bir partition olabilecegi gibi bir dizinde olabilir. Her bir disk icin bir OSD deamon calisiyor sistem uzerinde.

Ceph Monitor (MON) = Ceph cluster’inin saglik durumun gozlemler ve tum durumu (OSD, MON, PG, and CRUSH maps) bilir. Tum ceph nodelar MON ile konusup durum bilgisini belirtir.

RBD = ( Tekrar ) block access

RGW = ( Tekrar ) object access

MDS (Metadata Server) = CephFS icin file Metadata’sini tutar

CephFS = ( Tekrar ) file access

}

Pool = RADOS tum objeleri “pool” icersinde tutar

OSD = Normalde her yazilan data’nin bir yedegi oldugun ilgili data’yi iceren primary OSD ve yedegini iceren secondary OSD mevcut olup . Olasi bir problemde eger primary kaybedilir ise secondary primary olabilir ve RADOS arkada ikinci bir OSD bulup sistem tekrardan tutarli hale getirebilir. Bu islemlerden “client” etkilenmez.

Client OSD ile direkt iletisime gecer = Bunun icin oncelikle Client MON’u sorgular ve tum ceph cluster haritasini elde eder ve gerektiginde ilgili OSD ile direkt iletisime gecebilir.

OSD lerde bir dosya sistemi kullanir = xfs , ext4 veya btrfs .

XATTRs = Veriye ek metadata bilgisi eklemek icin kullanilir , sanki http request veya response’a header eklemek gibi.

Journal = Ceph’de journaling  yapan file sistem kullandigindan datalar once log’a sonra dosya sistemine yazilacaktir. Performans direkt etkileneceginden journal diski SSD olmasi gerekmektedir, daha sonra data asil file sistem’e sync olacaktir.

{

Screen Shot 2015-12-29 at 15.22.59

}

OSD RAID istemez = her biri standalone disk olabilir fakat bazi durumlarda raid yapilabilir , cok diskli sunucularda her disk icin calisacak OSD deamon icin RAM yeterli olmayabilir.

librados = C Kutuphanesi , uygulamanin direk RADOS ile iletisime gecmesini sagliyor.

KRBD = Kernel RBD

Ceph Object Gateway = Kendine has kullanici yonetimi vardir , load balance icin birden fazla GW olabilir. FastCGI-capable web server

Object = neye benzer derseniz (asagida) , bunlarin hepsi OSD lere yaziliyor  {

Screen Shot 2015-12-29 at 16.55.40

}

CRUSH Lookup =

  1. Client MON a baglanip Cluster MAP i cekiyor
  2. Client yazma isteginde bulunuyor ve data isim ve pool adi ile objeye cevriliyor
  3. Obje Placement Group ID ile hash’leniyor
  4. Daha sonra CRUSH algoritmasi sayesinde primary OSD bulunuyor
  5. Client direkt ilgili OSD ile iletisime gecip veriyi yaziyor
  6. Datanin yazildigi Node tekrarda CRASH Lookup yaparak ikinci Placement Group ve OSD bulur ve veri yazilir
  7. Veri yedekliligi saglanir

{

Screen Shot 2015-12-29 at 17.14.32

}

veya

{

Screen Shot 2016-01-13 at 14.47.05

}

Ortamdan Haberdar Demistik = Gordugunuz gibi DC, Sira , Kabin hepsini belirtebiliyorsunuz, bu liste sistem tarafindan yaratildigi gibi mudahale etme sansinizda var. Bu yapi onemli cunku yedeklilik buna gore sekilleniyor.

{

Screen Shot 2015-12-29 at 17.35.52

}

Recovery ve Rebalance = Olasi bilesen kaybi ve sisteme yeni eklenen OSD ler oldugunda sistem otomatik recovery ve rebalance islemi yapar. Yeni eklenen OSD leri “0” yuk parametresi ile girmeniz ve degeri kontrollu bir sekilde yukselmeniz oneriliyor.

Placement Group (PG) = Sanal kontenyner olarak adlandirabiliriz , sistemde bir suru obje olacagini dusunurseniz , bunlari daha kolay bulunabilmesi icin bir cesit guruplama / ara katman . Replikasyon sayiniza gore birden fazla OSD ile iliski icindedir.

Screen Shot 2015-12-29 at 18.16.09

PGP = PG

PG Hesaplama =  Cikan sonuclari 2 katlari ile yuvarlayin 🙂

{

Ceph Cluster Basina
Toplam PG = (Toplam OSD * 100) / replikasyon_sayisi

Ceph Cluster Pool Basina

Toplam PG = (Toplam OSD * 100) / replikasyon_sayisi / pool sayisi

}

Bir bakima  OSD ler yan yana gelerek PG leri yaratirlara , PG lerin durumuda haliyle altindaki OSD lerin saglikli calisip calismadiklarina bagli , bunu icin OSD lerden primary olan ayni zamanda diger OSD lerle arasinda peering kurar ve bu peering’in status eger ok ise PG aktif ve calisiyor demektir baska bir deyisle bu PG e veri yazabiliriz demek oluyor.

Acting Set = PG den sorumlu olan OSD ler veya baska bir deyisle PG olusturan OSD ler 🙂

Ceph Cluster MAP = MON + OSD + PG + CRUSH + MDS

epoc = bir cesit versionlama veya numaralama

CRUSH Rule = replika veya erasure coding

CRUSH Rule Resimle ve Koruma = {

Screen Shot 2016-01-13 at 14.48.43

}

Background Petrol Read = {

http://www.dell.com/downloads/global/power/ps1q06-20050212-Habas.pdf

}

 

apache logs – fluentd – mongodb – Hizli , sipsak loglari toplamaca …

Senaryomuz ;

  • Elimizde bir adet sanal makinemiz mevcut, uzerine ubuntu kurulmus , apache yuklenmis , free bir web site template ile icerik yaratilmis durumda.
  • Yaratilan apache access log’larini hem aggregate edip hemde tek bir yere toplayacagiz
  • Hem store olarak hemde uzerinde sorgulama yapmak icin MongoDB kullanacagiz

 


 

Hizlica tek node mongodb kuralim 

Kullanilacak isletim sistemi

noroot@mongodb01single:~$ lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 14.04.3 LTS

Release: 14.04

Codename: trusty

noroot@mongodb01single:~$ sudo apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv 7F0CEB10

[sudo] password for noroot:

Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –homedir /tmp/tmp.Ijdtvnfxbw –no-auto-check-trustdb –trust-model always –keyring /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver hkp://keyserver.ubuntu.com:80 –recv 7F0CEB10

gpg: requesting key 7F0CEB10 from hkp server keyserver.ubuntu.com

gpg: key 7F0CEB10: public key “Richard Kreuter <richard@10gen.com>” imported

gpg: Total number processed: 1

noroot@mongodb01single:~$ echo “deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse” | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list

deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse

Tekrar guncelleyelim

noroot@mongodb01single:~$ sudo apt-get update

Kuralim gitsin 

noroot@mongodb01single:~$ sudo apt-get install mongodb-org

Varsayili olarak 127.0.0.1 uzerinden ve 27017 portunu dinler , asagidaki satiri devre disi birakin

#  bindIp: 127.0.0.1

sudo vi /etc/mongod.conf

Env degerlerine dikkat mutlaka UTF8 olsun , mongo yazili shell’e dusmeden once bunu yapin

noroot@mongodb01single:~$ cat /etc/environment

PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games”

LANG=en_US.utf-8

LC_ALL=en_US.utf-8

Mongo servisine bir restart 

noroot@mongodb01single:~$ sudo service mongod restart

mongod stop/waiting

mongod start/running, process 1283


 

Fluentd Konfigrasyonu 

 

Oncelikle td-agent.conf dosyasini editleyelim

noroot@mongodb01single:~$ sudo vi /etc/td-agent/td-agent.conf

Dosyanin en sonuna asagidaki satirlari ekleyin …

<source>

#Bildigimiz tail ile okuayacagiz apache logunu

type tail

#Bu arada eski log dosyaslari okunmayacak, sadece yeni gelenler

format apache2

#Apache log dosyasi ve yolu

path /var/log/apache2/access.log

#Log dosyasini okurken nerede kaldigini bilmek icin pos file okunuyor

pos_file /var/log/td-agent/apache2.access_log.pos

#Routing i belirtmek icin etiketliyoruz

tag apache.access

</source>

<match apache.access>

#Mongo ya atacagiz

type mongo

#Mongodb db adi + collection adi

#Bu arada default kurulumda kullanici adi ve sifre geregi yok

database apachedb

collection accesslogs

#Mongodb dinledigi port ve ip adresi

host 10.111.21.161

port 27017

#Mongoya datayi atam suresi

flush_interval 10s

#Zaman etiketinin oldugunu garanti edelim

include_time_key true

</match>

 

ve servisi restart edin

noroot@apache01fluentd:~$ sudo service td-agent restart

* Restarting td-agent  td-agent

Logdan kontrol edelim , calisiyor mu cidde ? 

noroot@apache01fluentd:~$ tail -f /var/log/td-agent/td-agent

td-agent.log     td-agent-ui.log

noroot@apache01fluentd:~$ tail -f /var/log/td-agent/td-agent.log 

collection accesslogs

host 10.111.21.161

port 27017

flush_interval 10s

include_time_key true

</match>

</ROOT>

2015-12-24 15:05:15 +0200 [info]: listening fluent socket on 0.0.0.0:24224

2015-12-24 15:05:15 +0200 [info]: listening dRuby uri=”druby://127.0.0.1:24230″ object=”Engine”

2015-12-24 15:05:15 +0200 [info]: following tail of /var/log/apache2/access.log

Simdi Mongo tarafini kontrol edelim 

mongo shell >

> show dbs

apachedb  0.000GB

local     0.000GB

> use apachedb

switched to db apachedb

> show collections

accesslogs

> db.accesslogs.findOne()

{

“_id” : ObjectId(“567beb25cec70e0835000001”),

“host” : “10.111.21.160”,

“user” : null,

“method” : “GET”,

“path” : “/”,

“code” : 200,

“size” : 23479,

“referer” : null,

“agent” : “ApacheBench/2.3”,

“time” : ISODate(“2015-12-24T12:54:58Z”)

}

>

Baslangic icin simdilik bu …

VM

OVS ile Biraz DB, Biraz Monitor/Troubleshoot , Biraz Openflow programlama

Simdi biraz daha ileri gidelim , uzun bir yazi oldu ama keyifli !

Oncelikle ihtiyacimiz olacak birkac sey ;

Bir onceki yazida ovsdb-client kullanarak OVS tablolarini listelemistik simdi aynisini bir benzerini asagidaki sekilde alalim.

noroot@kvm-ovs-server1:~$ sudo ovsdb-client get-schema

Not : bu komutu >  sudo ovsdb-client get-schema | python -m json.tool < seklinde kullanabilirsiniz veya ciktiyi  http://www.jsoneditoronline.org aktrip direk grafik uzerinden harekete edebilirsiniz .

Screen Shot 2015-12-15 at 17.13.10

Read the rest of this entry

Openstack Networking Ogrenmeden once bilinmesi gerekenler …

Openstack networking’i anlamadan once asagidaki konulari anlamak gerekiyor;

  • cgroup / namespace
  • Linux Networking Namespace
  • ip ve iproute2 paketi
  • Networking Namespace Yaratma
  • veth ve veth pair
  • tun/tap interface
  • Patch port

Cgroup (resource management) / Namespace (process isolation)

Cgroup / Namespace kavramlari benim container’larla beraber duymaya basladigim (ozellikle LXC , Docker ile) bir Linux Kernel ozelligi.
Cgroup konumuz ile cok alakali degil ama kisaca bilmekte fayda var, cgroup hardware kaynagini task ve kullanicilara paylastirmaya yariyor, bunu yaparkende kaynagin tahsisi, onceliklendirmesi, erisimin engellenmesi, yonetimi ve monitor edilmesini sagliyor.

Namespace ise bizim icin su an daha onemli olan process isolation’i sagliyor (tum processler sistem processlerinde ayri , sanki overlay networkler gibi 192.168.0.0/24 u tum tenantlar tarafindan kullanilabilmesi gibi ) veya baska bir deyisle basit anlamda process sanallastirma . 5,6 tip namespace var PID (process), Network (network katmani), UTS (hostname) , Mount (Disk Erisimleri) , user (UIDs) ve IPC . Muhtemelen farkli namespace lerde mevcut fakat uygulanmis degiller gibi .

Linux Networking Namespace

Mantiksal olarak var olan “network stack” kopyasi , snapshot’i , sag tus -> copy ‘ si 🙂 . Birbirinden bagimsiz route , firewall ve network device’lar (mesela loopback) . SNMP , socket , /procfs , /sysfs.

Daha gercek dunyadan dusunmek  gerekir ise boot etmis bir linux isletim sistemi uzerinde , eth0/em1/lo gibi interface’leri olan meseal veth0(sanal ethernet karti) gibi , sanki birden fazla container/sanal makine kosuyorda her birinin kendi ip adresi varmis gibi , iptables -L -v -n yapinca ana isletim sisteminden farkli kurallari olan , netstat -an yapildiginda yine  ana isletim sisteminden farkli socket lerin oldugunu dusunun.

Networking Namespace overlay networking kullanimini olagan kilar.
Read the rest of this entry

Hizlica ve Esitliklerle Docker – Adim 1

Amac = Dagitik uygulamalari yaratmak , bir yerden baska bir yere hizlica tasimak ve calistirmak .

Soyle bir amacda olabilir = Illa dagitik degil ya monolithic uygulamalar icinde kullanilabilir, kime ne !!!!

Paketlemek = Uygulamanin calismasi icin gerekli olan OS + library + dependency bir araya getirmek.

Baska Bir Deyisle Paketleme = Kodumuz (git uzerinde) + diyelimki  php + apache2 lazim + PHP icin ek moduller (SimpleXML) gibi

Docker = Open Platform + Amac + Paketleme

Docker = Benim icin karakutu demek !  + Icine ne koyduysaniz hersey problemsiz ve %100 calisiyor kabul edilmeli

Kurulum yapmadan once ;

sourcing (linux source command) = dosyayi oku ve komutlari calistir demek

Ubuntu icin docker paketi = docker.io

Kernel > 3.10 

{

noroot@kvm-ovs-server2:/etc/bash_completion.d$ uname -r”

3.16.0-55-generic

}

Read the rest of this entry

OVS, Benim icin yeni bir baslangic – 1

Merhaba ,

Bu yazi aslinda kvm-benim-icin-yeni-bir-baslangic-networking-1 OVS ‘ cesi diyebiliriz. Tabirler icinde buraya bakmanizi rica edecegim.

Oncelikle bir Ubuntu isletim sistemi uzerinde hangi “openvswitch” paketleri var bi ona goz atalim.

noroot@kvm-ovs-server1:~$ apt-cache search openvswitch

neutron-plugin-openvswitch – Neutron is a virtual network service for Openstack – Open vSwitch plugin

neutron-plugin-openvswitch-agent – Neutron is a virtual network service for Openstack – Open vSwitch plugin agent

openvswitch-common – Open vSwitch common components

openvswitch-controller – Open vSwitch controller implementation

openvswitch-dbg – Debug symbols for Open vSwitch packages

openvswitch-pki – Open vSwitch public key infrastructure dependency package

openvswitch-switch – Open vSwitch switch implementations

openvswitch-datapath-dkms – Open vSwitch datapath module source – DKMS version

openvswitch-datapath-source – Open vSwitch datapath module source – module-assistant version

openvswitch-ipsec – Open vSwitch GRE-over-IPsec support

openvswitch-test – Open vSwitch test package

python-openvswitch – Python bindings for Open vSwitch

Ilk KVM kurulum makalesi aksine bridge-utils kurmuyorum, buna ihtiyac olmayacak cunku herseyi OVS programciklari tarafindan yapilacak (ovs-vsctl gibi)

noroot@kvm-ovs-server1:~$ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder

Read the rest of this entry

Esitliklerle Openstack Networking – Neutron

Instance = VM = sanal makine

OVS = Open vSwitch = VMware vSS gibi

OVS = Tunneling + QoS + Monitoring (Netflow) + Yonetim + Otomizasyon (Openflow ve OVSDB sayesinde)

OpenFlow = SDN Controller ile OpenFlow switch arasindaki iletisim protokol’u

OpenFlow = Network paketinin izleyecegi yolu belirler ve yaratir

OVSDB = OpenFlow gibi oda bir protokol “OVSDB Protocol” = Yonetim ve Konfigrasyondan sorumlu =  OpenFlow a gore daha uzun metrajli islemleri icin mesela tunel , bridge , port , datapath islemleri yaratma/silme/guncelleme = https://tools.ietf.org/html/draft-pfaff-ovsdb-proto-00

Virtual Switch = OVS = L2 Agent = VM’lerin sanal vNIC leri buraya baglaniyor = vSwitch

Router =  L3 Agent = Virtual Router = Fiziksel router’in sanal hali

Floating IP = VM haberdar olmadigi fakat disardan iceriye erismek icin kullanilan IP adresi

Tenant = Musteri/Organizasyon

Tenant Network = Musteri Network’u = 192.168.0.0/24 = Mesela Web Tier, Database Tier gibi

Flat = untagged = herkez ayni networkde

Local = isolated = VM’in kostugu makine uzerinde networking = disari cikis yok

Tenant Network = Flat + Local + VLAN

GRE/VXLAN = Overlay Networks = Tum tenantlar 192.168.0.0/24 kullaniyorlar , tekrar tekrar tekrar = iletisim noktadan noktaya ve tunelleme kullaniliyor

Provider Network = VLAN ve Flat icin kullaniliyor

Flat Provider Network = Instance/VM leri direkt external networklere baglamak icin = Ornegin Openstack l3-agent degilde halihazirdaki fortinet + netscaller gibi cihazlari kullanmak istiyorsaniz

L3 High Availability = VRRP = Virtual Router / Floating IP leri koruma = Her bir musteri/organizasyon Virtual Router’i farkli bir Network Node uzerinde bulunur/dagitilir = Aktif/Pasif virtual router’lar

Network Node = Routing + DHCP + Metadata

Neutron = OpenStack Networking

Compute = HP = Sanal makinelere CPU/RAM

OVS-Agent = Network ve Compute Node’lar uzerinde calisan bir ajan = L2 Agent = OVS Plugin uzerinden kurulacak tunel ve flow bilgisini alir ve OVS’i programlar

External Network = Internet

Security Group = Firewall Kurallari = Compute Instance uzerinde = SG

Set edilmez ise Default Security kurali uygulanir = Iceri giris yok + Disari cikis any

SG LBaaS VIP , virtual router interface ve instance’a uygulanir

LinuxBridge + OVS + NSX + NEC + Ryu destekler SG (Biraz Master Yoda tarzi dusuk )

OVS = Open vSwitch = Bridging Replace = GRE / VXLAN tunelleme destekler

ML2 = Networking Plugin = Core Plugin

ML2 Onemli = Cunku olmasaydi tum saglayicilar tum servisleri IPAM , DB Access , Virtual Network ID bastan yaratmalari gerekecekti

ML2 Network Type = local + GRE + VLAN + VXLAN + Flat

ML2 Mechanics = OVS , Linuxbridge , Arista , Cisco

Neutron Service Plugins = LBaaS+FWaaS+L3 Agent

Nova Networking = OOOOOOOO Nooooooooooo (kullanima kalkti o/belki vardir hala)

Neden Neutron = Yeni ozellikler LBaaS/FWaaS + ML2 + 16 Milyon Network + Overlapping + network namespaces

Network Namespace = Izolasyon = Farkli network instance’lari = Her bir namespace icin farkli iptables/routing ve ethernet arabirimleri

veth pairs = Iki farkli Namespace’i birbirine baglar

L2Population = No BUM trafik 🙂

BUM = Broadcast + Unicast + Multicast

L3 Agent = virtual layer 3 router = L2 Networklere gw servisi = iptables/NAT/Routing

External IP Range = L3 Agent uzerinde otomatik konfigre ediliyor = IP adresleri virtual layer 3 router’lara assign ediliyor

Neutron DHCP Agent = Tenant networklere DHCP servisi verir = dnsmasq

ovsdb-server = Open vSwitch database server = Konfigrasyon ve durum veritabani = JSON RPC Request/Response = /etc/openvswitch/conf.db

durum = L2 learning table + L3 Forward table + ACL + QoS Policy + Netflow/IPFLEX/sFLOW

ovsdb-tool = Open vSwitch database yonetimi = DB yaratma , sorgulama 🙂

ovs-vswitchd = Lokal sunucu uzerindeki OVS switch lerini yonetir ve kontrol eder = Aciliste tum konfigrasyonu db’den okur ve acar = L2 Switching MAC Learning = VLAN = Port Mirroring

ovs-vswitchd = Flow Table

datapath = Verinin akis yolu

hash lookup table = OVS Kernel Module Flow Cache

Fast Path = OVS Kernel uzerinden

Slow Path = OVS vswitchd user space uzerinden

DPDK = Intel userspace’de Fast Path’den hizli islem yapiyor = OVS Kernel replace for Fast Path

Netlink = ovs-vswitchd ile kernel arasindaki iletisim protokolu burada TCP degil Netlink konusuluyor = Unix domain socket benzeri = kernel <-> userspace arasi baglanti

Package Classifier = Paket islenirken hangi OpenFlow kuralinin uygulanacagini belirler

brt-int = Instance vNIC’ler bu bridge a bagli = vswitch

br-tun = Tuneller uzerinden kosan tenant ve dis baglanti trafigi buradan akiyor

br-ex = Dis baglanti icin kullanilan bridge  = Floating IP ler burada = Network Node uzerinde

qvo = openvswitch tarafindaki veth cifti

qvb = bridge tarafindaki veth cifti

qbr = bridge

qr = l3-agent tarafindan yonetilen port , router tarafinda

qg = l3-agent tarafindan yonetilen port, gw tarafi

patch port = uplink port, birden fazla bridge birbirine patch port ile baglanip tek bir bridge olusturuyor

 

Muhtemelen kacirdigim cok sey vardir , onlarda zamanla eklenecektir buraya.

VM