Linux

Lsyncd, ” Live Syncing Daemon ” anlamına gelir, adından da anlaşılacağı gibi, lsyncd, dosyaları ve dizinleri belirli bir aralıktan sonra yerel olarak ve uzaktan senkronize etmek veya çoğaltmak için kullanılır. Arka uçta rsync & ssh kullanır.

Lsyncd, ana sunucudaki dizini izlediği Ana ve Bağımlı mimaride çalışır, herhangi bir değişiklik veya değişiklik yapılırsa, lsyncd belirli bir zaman aralığından sonra aynısını bağımlı sunucularında çoğaltır.

Daha önce sizlerle paylaşmış olduğumuz, GlusterFS Nedir? ve Kubernetes Nedir? makalelerine gelen en fazla yorumlardan biriside lsyncd hakkında idi dolayısıyla bu yazıda CentOS 7 ve RHEL 7’de lsyncd’nin nasıl kurulacağını ve kullanılacağını tartışacağız.

Senaryo : “/var/www/html” klasörünü Ana sunucudan Bağımlı sunucuya senkronize etmek istediğinizi varsayalım.

Ana Sunucunun IP’si = 192.168.1.14
Bağımlı Sunucunun IP’si = 192.168.1.15
Senkronize edilecek dizin = /var/www/html
Önce Ana ve Yedek Sunucu arasında Anahtar tabanlı kimlik doğrulamayı etkinleştirin.
Ana sunucuya giriş yapın ve ssh-keygen komutunu kullanarak genel ve Özel anahtarları oluşturun.

Centos 7de Lsyncd Nasil Kurulur ve Kullanilir LSYNCD Dosya Esitleme Replikasyon Kullanimi
Şimdi ortak anahtarı ssh-copy-id komutunu kullanarak bağımlı sunucuya kopyalayın


ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]

Adım:1 Ana Sunucuya (MASTER) Giriş Yapın ve Lsyncd Paketini Kurun

Aşağıdaki yum komutunu kullanarak lsyncd bağımlılık paketlerini kurun.


yum install -y lua lua-devel pkgconfig gcc asciidoc

yum komutunu kullanarak lsyncd paketini kurmak için, önce EPEL deposunu etkinleştirin, çünkü varsayılan depolarda lsyncd rpm mevcut değildir.

yum -y install epel-release

Adım:2 Lsyncd’nin Yapılandırma Dosyasını Kurun

Örnek Yapılandırmayı /etc/lsyncd.conf dosyasına kopyalayın

[ [email protected] ~]# cp /usr/share/doc/lsyncd-2.1.5/examples/lrsync.lua /etc/lsyncd.conf

Yapılandırma dosyasına aşağıdaki satırları ekleyin.

[ [email protected] ~]# cat /etc/lsyncd.conf
----
-- lsyncd için kullanıcı yapılandırma dosyası.
--
-- Varsayılan rsync için basit bir örnek.
--
ayarlar = {
 logfile = "/var/log/lsyncd.log",
 statusFile = "/var/log/lsyncd.stat",
 durumAralığı = 2,
}
senkronizasyon{
 varsayılan.rsync,
 kaynak="/var/www/html",
 hedef="192.168.1.15:/var/www/html",
 rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_rsa",}
}
[ [email protected] ~]#
Centos 7de Lsyncd Nasil Kurulur ve Kullanilir LSYNCD Dosya Esitleme Replikasyon Kullanimi2

Adım:3 Hizmeti başlatın ve yeniden başlatma sırasında etkinleştirin
[ [email protected] ~]# systemctl start lsyncd
[ root@linuxtechi ~]# systemctl lsyncd  enable
ln -s '/usr/lib/systemd/system/lsyncd.service' '/etc/systemd/system/multi-user.target.want/lsyncd.service'
Adım:4 Çoğaltma ve Günlük Raporunu Analiz Edin.

Gördüğümüz gibi, verileri senkronize etmek için “ root ” kullanıcısı kullanıyoruz, ihtiyacınıza göre kullanıcı adını değiştirebilirsiniz.

Günlük Dosyasında, replikasyonun tamamlanıp tamamlanmadığını, replikasyonun durumunu görebiliriz.

[ [email protected] ~]# tail -10 /var/log/lsyncd.log
26 Temmuz Pazar 12:53:04 2015 Normal: özyinelemeli başlangıç ​​rsync: /var/www/html/ -> 192.168.1.15:/var/www/html/
Paz 26 Tem 12:53:56 2015 Normal: "/var/www/html/" başlatması tamamlandı.
[ [email protected] ~]#

Stat dosyasını kullanarak lsyncd durum Raporunu görüntülüyoruz. Örnek Örnek aşağıda gösterilmiştir


[[email protected] ~]# more /var/log/lsyncd.stat

Lsyncd status report at Sun Jul 26 12:53:58 2015
Sync1 source=/var/www/html/
There are 0 delays
Excluding:
nothing.

Inotify watching 849 directories
1: /var/www/html/
2: /var/www/html/catalog/
3: /var/www/html/catalog/controller/
4: /var/www/html/catalog/controller/module/
5: /var/www/html/catalog/controller/checkout/
6: /var/www/html/catalog/controller/api/
7: /var/www/html/catalog/controller/payment/
8: /var/www/html/catalog/controller/tool/
9: /var/www/html/catalog/controller/product/
———————
848: /var/www/html/system/library/db/
849: /var/www/html/system/modification/
[[email protected] ~]#

 

Adım 5 : File Permission Root Yerine kullanıcı adı olsun
rsync içerisine aşağıdaki parametreleri ekliyoruz ve artık senkron olan dosyalar kullanıcı adı ve grubuna göre senkron olacaktır.


compress = true,
verbose = true,
update = true,
perms = true,
owner = true,
group = true,

LSYNCD Dosya Esitleme Replikasyon Kullanimi

Gluster yatayda büyüyebilen, ücretsiz ve açık kaynak kodlu bir network dosya sistemidir. Günümüzün değişen depolama ihtiyaçları göz önüne alınalarak dağıtık, bulut depolama çözümü olarak ortaya çıkmıştır.

Detayları aşağıda yer alan adımlar takip edilerek Centos 7 minimal işletim sistemi üzerine Gluster kümesi (cluster) kurulumu yapılabilir. Bu makalede 2 sunucudan oluşan bir küme üzerine nasıl Gluster Cluster’ı kurulacağına dair detayları paylaşacağım. Kurulum yapılan sunucularda sadece GlusterFS kullanımına verilecek /dev/sdb diskleri olduğu varsayılmaktadır. Gluster Cluster’ın topolojisi ve disk sayısı ihtiyaçlar doğrultusunda çeşitlilik gösterecektir. Aşağıdaki kurulum adımlarını takip ederek ve topoloji dosyasını güncelleyerek kendi ihtiyaçlarınız doğrultusunda bir kurulum yapabilirsiniz. Gluster Cluster kurulumu için farklı yöntemlerle ilerlenebilmektedir. Bu makalede detaylarını paylaştığım adımlar Heketi üzerinden nasıl kurabileceğinizi gösterecektir. İlerleyen makalelerde farklı yöntemleri de bulabilirsiniz.

Kuruluma başlarken sunucuların birbirlerini gördüğü ve dns üzerinden gidebildikleri, /etc/hosts dosyasında kayıtları olduğu kontrol edilmelidir.

GlusterFS tarafından kullanılacak olan dm_thin_pool Kernel modülü aşağıdaki komutla yüklenir;


modprobe dm_thin_pool

dm_thin_pool modülünün restartlar sonrası da aktif olması için /etc/modules-load.d altına girdi eklenmelidir.;


echo dm_thin_pool >> /etc/modules-load.d/dm_thin_pool.conf

Redhat sunucularda aşağıdaki içerikle /etc/yum.repos.d/Gluster.repo adresinde bir repo tanımı yapılmalıdır;


[gluster6]
name=Gluster 6 Repository
baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-6/
gpgcheck=0
enabled=1

Centos 7’de ise aşağıdaki komutla gerekli RPM depolarının kurulumu kolaylıkla yapılabilir;

yum install -y centos-release-gluster

Depo tanımları ardından aşağıdaki komutlar yardımıyla Gluster kurulumu ve servisinin başlatılması sağlanır;


yum install -y glusterfs-server
systemctl start glusterd
systemctl enable glusterd

İşletim sisteminde firewall aktif ise aşağıdaki komutla kapatılır;


systemctl stop firewalld
systemctl disable firewalld

Firewall’u tamamen kapatmayı tercih etmiyorsanız, alternatif olarak aşağıdaki komutla erişecek ip’ler için tanımlar yapmalısınız;


firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="[ERİŞİM_VERİLECEK_İP_ADRESİ]" accept'
firewall-cmd --reload

Root kullanıcısı için sunucular arası şifresiz geçiş yapılandırılır.

Heketi Kurulumu

Heketi kurulumu yapılacak master sunucuya geçilerek aşağıdaki komutlarla paket kurulumu yapılır. Bu sunucu Gluster Cluster üyesi bir sunucu olabileceği gibi ayrı bir sunucuda olabilir. Bizim senaryomuzda Cluster’a üye bir sunucu üzerinde kurulum yapacağız. Devam eden heketi kurulum ve yapılandırma adımları aynı sunucuda olmalıdır.

 


yum -y install heketi heketi-client

Heketi varsayılan olarak 8080 portunu kullanmaktadır. Bu port başka bir uygulama tarafından kullanılıyorsa /etc/heketi/heketi.json dosyası içerisinden port güncellenmelidir.

GlusterFS – Heketi ve Cluster Kurulumu

Kurulum sırasında işletim sisteminde heketi servis kullanıcısı otomatik olarak oluşturulacaktır. Heketi kullanıcısının yapılandırma ve yönetim işlemlerini yapabilmesi için aşağıdaki komutlarla diğer cluster sunucularına şifresiz giriş tanımlanır;


ssh-keygen -b 4096 -t rsa -f /etc/heketi/heketi_key -N ""
ssh-copy-id -i /etc/heketi/heketi_key.pub [email protected]

ssh-copy-id komutu Gluster Cluster’ına üye tüm sunucular için yapılmalıdır.

Oluşturulan ssh anahtarı heketi kullanıcısına verilir;


chown heketi:heketi /etc/heketi/heketi_key*

Not: Heketi kurulum işlemleri cluster’a üye bir sunucu üzerinde yapılıyorsa host adıyla kendisi için de bu komutu çalıştırdığınıza emin olun.

/etc/heketi/heketi.json dosyasında aşağıdaki şekilde düzenlemeler yapılır;

GlusterFS – Heketi ve Cluster Kurulumu2

1 ile işaretli değer Heketi server’ın hangi port üzerinden açılacağını belirtmektedir. 2 ile işaretli değer yetkilendirme yapılacağını belirtmektedir. 3 ile işaretle değer admin şifresidir, kendi belirlediğiniz bir şifre verebilirsiniz.4 ile işaretle değer kullanıcı şifresidir, kendi belirlediğiniz bir şifre verebilirsiniz.

Yapılandırma değişikliği ardından Heketi başlatılır;


systemctl start heketi
systemctl enable heketi

Heketi kurulumu aşağıdaki komutla test edilebilir;


curl http://localhost:8080/hello

GlusterFS – Heketi ve Cluster Kurulumu3

GlusterFS Topolojisi’nin Heketi-cli ile oluşturulması

GlusterFS kurulumunu heketi-cli ile yapabilmek için öncelikle kuruluma dair topoloji bilgisi hazırlanmalıdır. Aşağıdaki içerikle topoloji.json dosyası oluşturulur. Dikkat ederseniz bu dosya içerisinde sunucu ve storage ip’leri ile bu sunuculardaki disk bilgileri yer almaktadır. Kendi ortamınız doğrultusunda bu bilgileri güncellemelisiniz.

 


{
"clusters": [
{
"nodes": [
{
"node": {
"hostnames": {
"manage": [
"gluster1.enterprisecoding.local"
],
"storage": [
"192.168.200.5"
]
},
"zone": 1
},
"devices": [
"/dev/sdb"
]
},
{
"node": {
"hostnames": {
"manage": [
"gluster2.enterprisecoding.local"
],
"storage": [
"192.168.200.6"
]
},
"zone": 1
},
"devices": [
"/dev/sdb"
]
}
]
}
]
}

Aşağıdaki komutla heketi-cli için gerekli ortam değişkenleri tanımlanır;


export HEKETI_CLI_SERVER=http://localhost:8080
export HEKETI_CLI_USER=admin
export HEKETI_CLI_KEY=N3f5BSNignLMKZdKNoZ6mVe4Z

Bu komutlardan HEKETI_CLI_KEY tanımında verilen değer yukarıdaki adımlarda heketi.json içerisinde admin kullanıcı için verilen şifre ile aynı olmalıdır.

Aşağıdaki komutla topoloji heketi-cli tarafından uygulanır;

heketi-cli topology load --json=topoloji.json


GlusterFS – Heketi ve Cluster Kurulumu4
alternatif olarak; ortam değişkenleri tanımlanmadan bu değerler komuta aşağıdaki şekilde eklenebilir;


heketi-cli -s http://localhost:8080 --user admin --secret 'N3f5BSNignLMKZdKNoZ6mVe4Z' topology load --json=topoloji.json

Oluşan topoloji bilgisi aşağıdaki şekilde görüntülenebilir;


heketi-cli topology info

Topoloji bilgisinde yer alan cluster id’si not alınmalıdır.

GlusterFS – Heketi ve Cluster Kurulumu5

Kubernetes cluster’ımızla konuşmak için kullandığımız komut “kubectl”, bash ve zsh için otomatik tamamlama desteği sağlamaktadır. Bu da cluster’ımızı yönetirken bizi gereksiz yazı yazmaktan kurtarıp hızlıca tab tuşunu kullanarak otomatik tamamlamasını sağlıyor. Örneğin “kubectl -n” yazıp tab tuşuna bastığımızda namespace’lerimizi listeliyor veya birkaç benzersiz harf yazdığımızda otomatik tamamlıyor ve bunu tüm parametrelerde kullanabiliyoruz. Hatta “kubectl” yerine “k” bile kullanabiliyoruz. Hayydi gelin hızlıca bunu nasıl yaptığımıza bir bakalım.

Öncelikle

apt-get install bash-completion

veya

yum install bash-completion

gibi basit bir komutla shell ekranında bash-completion yüklemesi yapıyoruz. (Farklı bir işletim sistemi kullanıyor iseniz buradan nasıl yükleneceğini kontrol edebilirsiniz.)

Bu komutlar /usr/share/bash-completion/bash_completion altına gerekli script’i oluşturmaktadır. Paket yöneticimize bağlı olarak bunu ~/.bashrc dosyamızın içine eklememiz gerekmektedir.

vi ~/.bashrc

komutu ile dosyanın içerisine girerek uygun bir yere

source /usr/share/bash-completion/bash_completion

yazıyoruz. Akabinde shell ekranımızı yeniden başlatıp

type _init_completion

yazdığımızda script’in çıktısını alabiliyorsak işlem tamam, kurulumu doğru bir şekilde yaptık demektir.

Şimdi ise tüm shell oturumlarında kubectl’in otomatik tamamlamasını sağlayacağız. Bunu yapmanın iki yolu vardır:

echo ‘source <(kubectl completion bash)’ >>~/.bashrc
kubectl completion bash >/etc/bash_completion.d/kubectl

Bunlara ek olarak bir de “kubectl” komutu yerine “k” komutunu kullanabilmek için aşağıdaki komutlar ile bir alias tanımlayabiliriz.

echo ‘alias k=kubectl’ >>~/.bashrc
echo ‘complete -F __start_kubectl k’ >>~/.bashrc

İşlemlerin akabinde komut satırınızı yeniden başlattığınızda kubectl otomatik tamamlıyor olacaktır. Emin olun, artık hayat daha kolay

 

Bu makale : kubernetesturkey.com adresinden alıntıdır.

Nedir?

Pod network cidr kubernetes clusterdaki podlarımızın cluster içi local networkde alacağı IPv4 bloğudur. Bu kubespray ve kubeadm kurulumlarında container network interface’de tanımlanır(CNI). CNI olarak en yaygın şekilde calico kullanılmaktadır.

Case

Bugün Hepsiburada private networkündeki bir kubernetes clusterda; hedef ip adresine worker node üzerinden gidebilirken, pod içinden gidemediğimiz konulu bir case geldi. Bu case üzerine yaptığımız inceleme sonucunda kubernetes pod cidr ip bloğu ile hedef ip adresimizin bulunduğu bloğun çakıştığını fark ettik. Hepsiburada gibi private ip bloklarının yetersiz kaldığı büyük ölçekli ortamlara bu tür durumlarla karşılaşmanız muhtemeldir.

Cluster productionda olduğu için olabilecek en uygun şekilde bu durumu çözmemiz gerekiyordu. Tabi bu durumun çözümü farklı yöntemlerle de olabilir fakat biz pod network cidr bloğunu Hepsiburada private networkünde bulunmayan boş farklı bir blok ile değiştirme üzerine yoğunlaştık. Bu makalemde de bu süreci neredeyse kesintisiz nasıl gerçekleştirdim bundan bahsedeceğim.

Başlayalım

Makalemin başında bahsettiğim gibi kubernetes clusterımızda Calico CNI kullanıyoruz. Yapacağım bu anlatım sadece Calico’yu kapsamaktadır.

Öncelikle kurulu olan calico üzerinde işlem yapabilmek için calicoctl deploy etmemiz gerekmetedir. Bunun için;

# kubectl apply -f https://docs.projectcalico.org/manifests/calicoctl.yaml

Sonraki komutları göndermeyi kolaylaştırmak için alias tanımlıyoruz.

# alias calicoctl="kubectl exec -i -n kube-system calicoctl -- /calicoctl "

Halihazırda var olan ip bloğunu görmek için aşağıdaki komutu kullanıyoruz.

# calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   DISABLED
default-ipv4-ippool   192.168.0.0/16   true   Always     false

Yeni ip bloğunu tanımlıyoruz.

# calicoctl create -f -<<EOF
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: new-pool
spec:
  cidr: 172.17.0.0/16
  ipipMode: Always
  natOutgoing: true
EOF

Şimdi halihazırdaki ip bloğunu silmek için aşağıdaki komutları çalıştırıyoruz.

# calicoctl get ippool -o yaml > ippool.yaml

pool.yaml şu şekilde gözükecektir.

apiVersion: projectcalico.org/v3
items:
- apiVersion: projectcalico.org/v3
  kind: IPPool
  metadata:
    name: default-ipv4-ippool
  spec:
    cidr: 192.168.0.0/16
    ipipMode: Always
    natOutgoing: true
- apiVersion: projectcalico.org/v3
  kind: IPPool
  metadata:
    name: new-pool
  spec:
    cidr: 172.17.0.0/16
    ipipMode: Always
    natOutgoing: true

Şimdi yeni eklediğimiz ip poolu siliyoruz. ippool.yaml şu hali alacaktır.

apiVersion: projectcalico.org/v3
items:
- apiVersion: projectcalico.org/v3
  kind: IPPool
  metadata:
    name: default-ipv4-ippool
  spec:
    cidr: 192.168.0.0/16
    ipipMode: Always
    natOutgoing: true

Düzenleme bitti, şimdi varolan ippoolu silmek için aşağıdaki komutu çalıştırıyoruz.

# calicoctl delete -f - < ippool.yaml

Tekrardan ip polları listeliyoruz ve sadece yeni eklediğimizin kaldığına ve enabled olduğuna dikkat ediyoruz.

# calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   DISABLED
new-pool              172.17.0.0/16    true   Always     false

İşlem sonrasında eski ip bloğunda oluşmuş podlarımızı silmemiz gerekiyor.

Tüm clusterdaki eskip ip blogunda çalışan podları listelemek için;

# kubectl get pod -A -o wide |grep 192.168

Namespace bazında toplu silmek için;

# kubectl get pod -n kube-system -o wide |grep 172.16. |awk '{print $2}' |xargs -I % kubectl delete pod % -n kube-system

Calicoyu ve coredns’i restart edelim. Burası önemli.

# kubectl -n kube-system rollout restart ds calico-node
# kubectl -n kube-system rollout restart deploy coredns

İşlem bu kadar, sildiğiniz podların yerine oluşan yeni podların yeni oluşturduğunuz networkten ip aldığını göreceksiniz. Böylece “neredeyse” sıfır kesintiyle calico CNI kullandığımız kubernetes clusterımızın pod network cidr ip bloğunu değiştirmiş oluyoruz.

Bu makale : kubernetesturkey.com adresinden alıntıdır.

İster developer olun ister sistemci ister devopscu monitoring hayatımızın olmassa olmazı. Daha önce yayınlamış olduğumuz Kubernetes Nedir? makalemize göz attıysanız şuan ki makalemizden devam edebiliriz. 3-5 ay önce k8s clusterlarımızın ssl expire tarihlerini kontrol ediyorduk, tabi o zamanlar bunu monitör etmiyorduk ve etmek de açıkcası pek aklımıza gelmemişti. Sonra güncellemeler vs ile bunun stabil hale getirilip sadece ssl için değil proxy, etcd vs gibi control plane komponentleri ile ds/deployment gibi data komponentlerini de gözetleme ihtiyacı oluştu. Sık sık restart eden var mı? Evict olan var mı? Image çekemeyen var mı? gibi gibi…

Hali hazırda zaten p8s(yazının devamında prometheus yerine bu ifadeyi kullanacağım ) kullanıyorduk. Ama bu klasik yaml’lar ile oluşturulmuş eski bir versiyonu.

Sorunlar

Operatorlar Nedir?

K8s varsayılan haliyle gelen her bir komponentinin yaşam döngüsü vardır. Misal pod kalkarken initcontainer’ı varsa önce onu çalıştırır sonra problara bakar bir şekilde exit olmuşsa, ve eğer controlerı da varsa (deployment,replicaset vs ) yeni bir isimle kendini tekrar oluşturur. Bunun yanında deamonset’lerde durum farklıdır, her bir node’da kendini kaldırır ve rollout restart vs gibi durumlarda yeni pod oluşturmak için önce o node üzerindeki eski podun terminate etmesini bekler.

Buraya kadar kulağa hoş geliyor fakat ya sizin uygulamanızın kendine has yaşam döngüsü ihtiyaçları varsa ve kurulum ile gelen k8s objeleri yeterli gelmiyorsa napıcaz? Bu durumda devreye operatorlar giriyor. Kendi ihtiyaçlarınıza göre k8s objeleri ve yaşam döngüleri üretebiliyorsunuz. Bu yazının temel konusu bu olmadığı için daha fazla uzatmayacağım.

Neden p8s-stack?

Prometheus stack aslında prometheus ve komponentlerinin, k8s üzerinde optimum şekilde ve kolaylıkla çalışması için yazılmıs operatordır. Yazının ilerleyen bölümlerine bize ne gibi avantajlar verdiğinden bahsedeceğim.

Başlayalım

Öncelikle bilgisayarınıza veya kurulumu nerden yapıcaksanız, vm vs, helm3 yüklemeniz gerekiyor.

Not: Helm2 ile de yükleyebilirsiniz ama helm2’nin tiller bağımlılığı ve tiller’da güvenlik açığı bulunduğundan helm3 kullanmanızı tavsiye ediyorum.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.

Helm reposunu ekleyelim. “Helm repo eklemek, apt’ye ppa eklemekten çokta farklı değil aslında, mantık olarak aynı, source-code’dan build edip kurup ya da deb paketlerini kurup dependency yönetimini sizin yerinize nasıl apt/yum/apk vs yapıyorsa helm’de k8s bağımlıklarını yönetiyor, ( deployment,service,pvc,rolebinding aklınıza ne gelirse )

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Ppa ekledik, sıra apt-get update’de;

$ helm repo update

Sonunda;

$ helm install --namespace monitoring p8s-stack prometheus-community/kube-prometheus-stack  -f prometheus-stack/values.yaml --version="${chartVersion}"

Burda chartVerison bölümü biraz isteğe bağlı isterseniz orayı kaldırıp latest ile devam edebilirsiniz.

Default values.yaml -> https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/values.yaml

Not: Sadece değişiklik yaptığınız kısımları yazdığınız bir values.yaml hazırlayıp, apply ederken onu verirseniz, helm değişiklerinizi kolay takip edersiniz hem de default yamlın içindeki kalabalıkla
uğraşmazsınız.

Eğer typo vs yapmadıysanız helm komutu sonunda,
kube-prometheus-stack has been installed. Check its status by running: 42 kubectl --namespace monitoring get pods -l "release=p8s-stack" 43Visit https://github.com/prometheus-operator/kube-prometheus for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.
çıktısı almanız gerekiyor. Eğer almadıysanız veya aldığınız halde bişeyler bozukssa, yazının sonuna bizim daha önce karşılaştığımız hataları ekledim, oraya bakabilirsiniz.

Prometheus ve Alertmanager Kurallarının Tanımlanması

prometheus-rules.yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  annotations:
  labels:
    app: kube-prometheus-stack
    release: p8s-stack
  name: kubernetesturkey-rules
  namespace: monitoring
spec:
  groups:
    - name: kubernetesturkey-rules
      rules:
        - alert: HostHighCpuLoad
          annotations:
            description: |-
              CPU load is > 80%
                VALUE = {{ $value }}
                LABELS: {{ $labels }}
            summary: Host high CPU load (instance {{ $labels.instance }})
          expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
            * 100) > 80
          for: 5m
          labels:
            notification: kubernetesturkey
            severity: critical
Prometheus rule’u her değiştirdiğimizde, her yeni bir tanımlama yaptığımızda, tek yapmamız gereken kubectl apply -f prometheus-rule.yaml yapıp arkamıza yaslamak.
Prometheus configi valid ise reload ederek uyguluyor, valid değil ise hata logunu basıyor.

Helm’e verdiğimiz values.yaml’da;

alertmanager:
  config:
    route:
      group_by: ['alertname']
      group_wait: 10s
      group_interval: 10s
      repeat_interval: 24h
      receiver: 'default'
      routes:
        - receiver: 'kubernetesturkey-alerts'
          match:
            severity: 'critical'
          continue: true
        - receiver: 'default'
          match:
            alertname: 'Watchdog'
    receivers:
      - name: 'kubernetesturkey-alerts'
        slack_configs:
          - send_resolved: true
            title: '[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonLabels.alertname }}'
            text: |-
              {{ if gt (len .Alerts.Firing) 0 }}
              *Alerts Firing:*
              {{ range .Alerts.Firing }}- {{ .Annotations.description }}
              {{ .Annotations.message }}
              {{ end }}{{ end }}
              {{ if gt (len .Alerts.Resolved) 0 }}
              *Alerts Resolved:*
              {{ range .Alerts.Resolved }}- {{ .Annotations.description }}
              {{ .Annotations.message }}
              {{ end }}{{ end }}
            icon_emoji: ':alert:'
            username: 'kubernetesturkey'
            channel: '#kubernetesturkey-alerts'
            api_url: 'Slack-web-hook'
      - name: 'default'

Bonus

Güncellemek için;

helm upgrade --namespace monitoring p8s-stack prometheus-community/kube-prometheus-stack -f prometheus-stack/values.yaml --version="${chartVersion}"

Bilinen Hatalar

Hata-1

Error: unable to build kubernetes objects from release manifest: error validating “”: error validating data: [ValidationError(Prometheus.spec): unknown field “probeNamespaceSelector” in com.coreos.monitoring.v1.Prometheus.spec, ValidationError(Prometheus.spec): unknown field “probeSelector” in com.coreos.monitoring.v1.Prometheus.spec]

Çözüm-1

kubectl delete crd prometheuses.monitoring.coreos.com kubectl delete crd prometheusrules.monitoring.coreos.com kubectl delete crd servicemonitors.monitoring.coreos.com kubectl delete crd podmonitors.monitoring.coreos.com kubectl delete crd alertmanagers.monitoring.coreos.com kubectl delete crd thanosrulers.monitoring.coreos.com kubectl delete crd probes.monitoring.coreos.com`

Hata-2

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Prometheus.spec): unknown field "probeNamespaceSelector" in com.coreos.monitoring.v1.Prometheus.spec, ValidationError(Prometheus.spec): unknown field "probeSelector" in com.coreos.monitoring.v1.Prometheus.spec]

Çözüm-2

kubectl delete crd prometheuses.monitoring.coreos.com kubectl delete crd prometheusrules.monitoring.coreos.com kubectl delete crd servicemonitors.monitoring.coreos.com kubectl delete crd podmonitors.monitoring.coreos.com kubectl delete crd alertmanagers.monitoring.coreos.com kubectl delete crd thanosrulers.monitoring.coreos.com kubectl delete crd probes.monitoring.coreos.com`

Hata-3

fake kubeproxy fail alert

Çözüm-3
kubectl edit cm/kube-proxy -n kube-system
açılan editörden "metricsBindAddresi" localhost'dan 0.0.0.0'a çekin, kaydedip çıktıktan sonra kube-proxy rollout-restart edin.
...
metricsBindAddress: 0.0.0.0:10249
...
:wq

kubectl rollout restart ds kube-proxy -n kube-system
kubectl rollout status ds kube-proxy -n kube-system
Hata-4

logda many-to-many hatası

Çözüm-4
prometheus-rules.yaml'içerisindeki label kısmını kontrol edin;

....

    app: kube-prometheus-stack // gibi

....

Bu makale : kubernetesturkey.com adresinden alıntıdır

Kubernetes hem beyan temelli yapılandırmayı hem de otomasyonu kolaylaştıran, container iş yüklerini ve hizmetleri yönetmek için oluşturulmuş,taşınabilir ve genişletilebilir açık kaynaklı bir platformdur. Kubernetes Google tarafından GO dilinde geliştirilmiş Cloud Native Computing Foundation(CNCF) tarafından desteklenen mevcut konteyner haline getirilmiş uygulamalarınızı otomatik deploy etmek, sayılarını arttırıp azaltmak gibi işlemler ile birlikte yönetmenizi sağlayan bir Konteyner kümeleme (container cluster) aracıdır.

Kubernetes Modüler Yapısı:

Kubernetis’de önemli özelliklerinden bir tanesi ise biz kubernetise istediğimiz yapıyı söylüyoruz ve kubernetes bunu bizim için oluşturuyor.Sonrasında da bu yapıyı gözlemliyor eğer yapı bizim beyan ettiğimiz yani deklare ettiğimiz durumun dışına çıkarsa da Kubernetes otomatik olarak bunu düzenliyor ve bizim istediğimiz konfigürasyona geri döndürüyor. Bu özelliği bir örnekle açıklamak istiyorum.
Biz kubernetese nginx:latest imajından bir yapı oluşturmasını isteyelim ve sistem genelinde’de 10 tane container çalışacak diyelim dış dünyaya’da 80 portundan yayınlanacağını deklare edelim.(Desired State yani istenilen durum).Kubernetes bizim istediğimiz bu yapıyı oluşturduktan belli bir süre sonra containerlardan birisi bir şekildi indi diyelim kubernetes bu durumu hemen fark edip belirttiğimiz özelliklerde bir container oluşturup istenilen durum ile mevcut durumu birbirine eşitleyecektir.

Kısacası Kubernetes açık kaynak,modüler yapı,beyan temelli çalışma ve otomatizasyon özelliklerine sahip popüler bir container orchestration aracıdır.

Kubernetes Komponentleri Nelerdir?

Bu bölüme geçmeden önce bu bölümün daha iyi anlaşılması için sizlere bir örnek vermek istiyorum.

Yukarıda verdiğim örnekten de tahmin edeceğiniz üzere aslında bütün bunlar bir kubernetes komponentini temsil ediyor.

Yönetim → Control Plane veya Master Nodes

yönetim komponentlerini temsil ediyor.

Üretim → Worker Nodes

üretim komponentlerini temsil ediyor.Şimdi bu komponentleri daha yakından tanıyalım.

Controller-manager altındaki controllerlar kubernetes clusterın mevcut durumuyla ondan istenilen durum arasında fark olup olmadığını denetlerler. Apiserver aracılığıyla etcd’de saklanan cluster durumunu inceler ve eğer mevcut durumla istenilen durum arasında fark varsa bu farkı oluşturan kaynakları oluşturur,günceller gerekirse siler ve bu durumu eşitler.Siz kubernetes uygulamınızın 2 pod olarak çalışmasını istenilen durum olarak bildirdiğiniz ve kubernetes’de bunu gerçekleştirdi. Uygulamanızın koştuğu 3 pod çalışmaya başladı fakat podlardan bir tanesi patladı. Controller-manager bu durumu algılayarak hemen bir pod oluşturulmasını sağlar. Bu sayede istenilen durum ile mevcut durum eşitlenir(desired state=current state).

— İş yüklerimiz worker node’lar üzerinde çalışır. Worker node dediğimiz containerları üzerinde çalıştırdığımız yani podlarımızı çalıştırdığımız esas yerlerdir.Bunlar üzerlerinde containerd,docker gibi bir container runtime barındıran cluster’a dahil olan sistemlerdir.Her worker node’da 3 temel komponent bulunur.

İlk ve en önemli komponent containerların çalışmasını sağlayacak container runtime dır. Varsayılan olarak bu docker dır fakat kubernetes docker runtime desteğini bazı nedenlerden dolayı bırakıp containerd’ye geçmiştir. Containerd’de aslında docker’dan farklı değildir. Hatta docker’da container oluşturma, çalıştırma altyapısı olarak containerd’yi kullanır. Özetle her kubernetes worker node’unda containerların çalışması için bir container runtime bulunur.

H/A bir object storage için GlusterFS güzel bir çözüm. Bu yazımda sizelere glusterfs kurulumu ve heketi ile nasıl dynamic provisioning yaptımızdan bahsedeceğim.

Örnek Enviroment aşağıdaki gibidir.

Bu yapıda Glusterfs1 nodunu aynı zamanda management için kullanacağız. Duruma göre +1 node management için ekleyebilirsiniz.

Öncelikle sunucular birbirinin adını çözebilmesi için hosts dosyasına ekleme yapıyoruz.

sudo cat >> /etc/hosts <<EOF
192.168.4.86 glusterfs1
192.168.4.87 glusterfs2
EOF

Şimdi Centos 7’de glusterfs kuruluma geçelim.


yum install -y centos-release-gluster
yum install -y glusterfs-server
systemctl enable glusterd
systemctl start glusterd

Varolan, sunucularımıza takılı diskleri listeliyoruz.


# fdisk -l

Disk /dev/vda: 17.2 GB, 17179869184 bytes, 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0002183f

Aygıt Açılış Başlangıç Bitiş BlokSayısı Kml Sistem
/dev/vda1 * 2048 2099199 1048576 83 Linux
/dev/vda2 2099200 33554431 15727616 8e Linux LVM

Disk /dev/mapper/centos-root: 14.4 GB, 14382268416 bytes, 28090368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/centos-swap: 1719 MB, 1719664640 bytes, 3358720 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Görüldüğü gibi /dev/vda olarak takılı bir disk gözüküyor. Her iki sunucuya sanallaştırma ortamımızdan yeni disk takıyoruz. Sunucuları reboot ediyoruz.

Sonrasında oluşturulan diskleri yapılandırmak için eklenen diski görüntülüyoruz. Örneğimizde /dev/sda olarak eklendiğini görmekteyiz.

# fdisk -l

Disk /dev/vda: 17.2 GB, 17179869184 bytes, 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0002183f

Aygıt Açılış Başlangıç Bitiş BlokSayısı Kml Sistem
/dev/vda1 * 2048 2099199 1048576 83 Linux
/dev/vda2 2099200 33554431 15727616 8e Linux LVM

Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x8262346b

Aygıt Açılış Başlangıç Bitiş BlokSayısı Kml Sistem
/dev/sda1 2048 104857599 52427776 8e Linux LVM

Disk /dev/mapper/centos-root: 14.4 GB, 14382268416 bytes, 28090368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/centos-swap: 1719 MB, 1719664640 bytes, 3358720 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Yeni diski lvm olarak yapılandırıyoruz.

fdisk /dev/sda
> n
> p
> 1
> t
> 8e
> w
> q

Glusterfs kurulumu tamamlandı şimdi management nodu olarak kullanacağımız GlusterFS1 noduna heketi kurulumuna geçiyoruz. Heketi Kubernetes ortamımızdan storage class ile dynamic provisioning yapmamızı sağlayacaktır.


yum install -y heketi heketi-client

Heketi’nin nodelara erişebilmesi için ssh-key oluşturuyoruz ve nodelara gönderiyoruz.


sudo -u heketi ssh-keygen
ssh-copy-id -i /var/lib/heketi/.ssh/id_rsa 192.168.4.86
ssh-copy-id -i /var/lib/heketi/.ssh/id_rsa 192.168.4.87

Heketi configini aşağıdaki gibi düzenliyoruz.


vim /etc/heketi/heketi.json

###
“executor”: “ssh”,
“_sshexec_comment”: “SSH username and private key file information”,
“sshexec”: {
“keyfile”: “/var/lib/heketi/.ssh/id_rsa”,
“user”: “root”,
“port”: “22”,
“fstab”: “/etc/fstab”
},
###

Heketiyi başlatıyoruz.

systemctl enable heketi
systemctl start heketi

Test ediyoruz.

curl http://localhost:8080/hello
Hello from Heketi

Cluster oluşturuyoruz.


export HEKETI_CLI_SERVER=http://localhost:8080
heketi-cli cluster create mycluster

Clusterımıza nodelarımızı ekliyoruz. ClusterID kısımlarına bir önceki komutun çıktısındaki cluster id verisini yazıyoruz.


heketi-cli node add --cluster=ClusterID --zone=1 --management-host-name=glusterfs1 --storage-host-name=HOST_IP
heketi-cli node add --cluster=ClusterID --zone=1 --management-host-name=glusterfs2 --storage-host-name=HOST_IP

GlusterFS nodelarımıza eklediğimiz diskleri clusterımıza tanımlıyoruz.


heketi-cli device add --name=/dev/sda1 --node=NodeID1
heketi-cli device add --name=/dev/sda1 --node=NodeID2

Evet, glusterfs ve heketi kurulumumuz tamamlandı. Şimdi bir volume oluşturalım.


heketi-cli volume create --size 10 --replica 2

GlusterFS clusterımızda yapacağımız işlemler bu kadar. Kubernetes ortamımıza geçip bir storage cluster oluşturuyoruz.


cat > gluster-dyn-sc.yml << EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: gluster-heketi
provisioner: kubernetes.io/glusterfs
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
resturl: "http://192.168.4.86:8080"
restauthenabled: "false"
volumetype: "replicate:2"
volumenameprefix: "k8s-dev"
clusterid: "CLUSTER_ID"
EOF


kubectl apply -f gluster-dyn-sc.yml

Persistent volume claim oluşturup test ediyoruz.


cat > gluster-dyn-pvc.yml <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-dyn-pvc
annotations:
volume.beta.kubernetes.io/storage-class: gluster-dyn
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
EOF


kubectl apply -f gluster-dyn-pvc.yml

Persistent volume claimleri listeleyerek STATUS kısmını Bound olarak görüyoruz.


kubectl get pvc
NAME STATUS CAPACITY ACCESS MODES STORAGECLASS AGE
gluster-dyn-pvc Bound 50Gi RWX gluster-dyn 8m

GlusterFS ücretsiz ve açık kaynak kodlu bir çeşit NAS (network attached storage) olarak düşünebileceğimiz yazılım tabanlı storage çözümüdür. High availability ve disaster recovery sunması öne çıkan özelliklerindendir. Fiziksel, sanal veya bulut tabanlı sunucularda glusterfs kullanılabilir. Container teknolojilerinde persistent storage volume olarak kullanılmaktadır. Redhat tarafından Openshift üzerinde kurumsal destekli olarak sunulmaktadır.

Ana özelliği olarak kolay bir şekilde yatayda veya dikeyde kesinti gerektirmeden büyüyebilmesi gösterilebilir. Glusterfs storage katmanına ya cluster’daki sunuculara ek alan sağlanarak veya cluster’a yeni sunucu eklenerek kesintisiz şekilde büyüme sağlanabilir. Yapısı itibariyle storage katmanında yedeklilik ve yüksek erişilebilirlik imkanı sağlar.

Brick glusterfs üzerinde en temel storage birimine verilen isimdir. Volume ise birden fazla brick birimin mantıksal olarak bileşimidir. Volumeler ile sunuculara alan sağlanmaktadır. Volume çeşitleri temel olarak distributed, replicated ve striped volume olarak 3 çeşittir.

Bu temel volume tipleri dışında yukarıda belirtilen tiplerin birlikte kullanılarak oluşturulabilen distributed-replicated ve distribusted-striped volume tipleri bulunur. Glusterfs varsayılan olarak distributed volume kullanılır.

Bahsettiğimiz volume tipleri arasındaki kullanılabilir veri depolama alanı arasındaki karşılaştırma aşağıdaki gibidir. Bu karşılaştırmada replicated volume tiplerinde kopya sayısı 2 olarak alınmıştır.Görüldüğü üzere yedeklilik sağlandıkça elimizde olan veri depolama alanından kullanılabilir alan olarak daha az miktar ortaya çıkıyor. Ayrıca aşağıdaki örnekte distributed ve striped volume tipleri kullanılabilir toplam alan olarak aynı miktarı veriyor ancak striped volume 1GB’dan daha büyük dosya saklayabilecekken distributed volume en fazla 1GB büyüklüğünde dosya saklayabiliir.

Distributed: 1G +1G =2G
Replicated: (1G+1G)=1G
Striped: 1G +1G =2G
Distributed Replicated: (1G +1G)+(1G +1G)=2G
Distributed Striped: 1G +1G+1G +1G=4G

Glusterfs’in client sunucular tarafında oluşturduğumuz volume’ler nasıl kullanılabilir duruma gelecek? Glusterfs volume file storage olarak client sunucularda FUSE (filesystem in user space), NFS (network file system) ve CIFS (common internet file system) formatlarında yapılabilmektedir. Client sunucularda block ve object storage olarakta kullanılabilir. Kullanım tipi client taraftaki ihtiyaca göre değişmektedir.

Heketi, glusterfs için oluşturulmuş RESTful tabanlı volume yönetim aracıdır. Volume yönetiminin manuel biçimde değil otomasyon döngüsü içerisinde yapılabilmesine olanak sağlar. Openshift, Kubernetes gibi konteyner orkestrasyon araçlarında dinamik olarak volume yönetimini yapar. Heketi’ye bir volume isteği geldiğinde ilk olarak glusterfs cluster içinde istenilen storage ayrılır. Ayrılan storage alanı formatlanıp mount edilir ve ilgili volumeler oluşturulup start edilir.

Heketi’nin sağladığı olanak ile sistem yöneticileri glusterfs de bulunan volume, disk, trusted storage pool gibi katmanları yönetmek durumunda kalmaz. API ile harici yapılabilecek otomasyonlar içinde kolayca entegre olabilir.

Heketi üzerinde işlem yapabilmek için heket-cli tool bulunmaktadır. Bu tool heketi ile API üzerinden haberleşerek işlemlerinin yapılmasını sağlar.

Bir GlusterFS birimi oluşturduktan sonra, uygulamanız için yeterli performansa sahip olduğunu doğrulamanız gerekir ve değilse, sorunun temel nedenini yalıtmak için bir yola ihtiyacınız vardır.

İki tür iş yükü vardır:

Profil oluşturma araçları

İdeal olarak, Gluster’da çalıştırmak istediğiniz asıl uygulamayı kullanmak en iyisidir, ancak uygulamalar sistem yöneticisine performans sorunlarının, özellikle gecikme (yanıt süresi) sorunlarının nerede olduğunu çoğu zaman söylemez. Dolayısıyla, Gluster’da yerleşik olarak, uygulamanın gördüğü performansı, uygulamayı değiştirmeden ölçebilen, istilacı olmayan profil oluşturma araçları vardır. Şu anda Gluster profil oluşturma yöntemleri, io-stats çeviricisine dayanmaktadır ve şunları içerir:

Kısacası, “uygulamam neden yanıt vermiyor”u anlamak için istemci tarafı profil oluşturmayı kullanın. ve Gluster biriminizin ne kadar meşgul olduğunu, ona ne tür bir iş yükünün uygulandığını (yani çoğunlukla okunur mu? küçük dosya mı?) ve G/Ç yükünün ne kadar iyi yayıldığını anlamak için sunucu tarafı profil oluşturmayı kullanın. hacim boyunca.

İstemci tarafı profil oluşturma

İstemci tarafı profil oluşturmayı çalıştırmak için,

/var/run/gluster/io-stats-pre.txtBu , istemcide belirtilen dosyayı ( ) oluşturur . gvp-client.sh gibi bir komut dosyası bu verilerin toplanmasını otomatikleştirebilir.

TBS: Farklı FOP’ların ne olduğu ve ne anlama geldikleri.

Sunucu taraflı profil oluşturma

Çalıştırmak için:

gvp.sh gibi bir komut dosyası bu prosedürü otomatikleştirmenize yardımcı olabilir.

Bu verileri sonradan işlemek için komut dosyaları şu anda geliştirme aşamasındadır, neye ihtiyacınız olduğunu ve verileri sunmak için neyin yararlı bir format olacağını bize bildirin.

Test araçları

Bu bölümde, çok çeşitli POSIX benzeri işletim sistemleri ve çalışma zamanı ortamları için Gluster performansını uygulamadan bağımsız bir şekilde ölçmek için kullanılabilecek bazı temel iş yükü testleri öneriyoruz. Daha sonra bu sonuçları yorumlamak için bazı terminoloji ve kavramsal çerçeve sağlıyoruz.

Burada önerdiğimiz araçlar, dağıtılmış bir dosya sisteminde çalışacak şekilde tasarlanmıştır. Bu, şu anda bile dosya sistemi karşılaştırmaları için nispeten nadir bir özelliktir! Tek bir sistemden çalıştırılabilen çok daha büyük bir kıyaslama seti mevcuttur. Tek sistem sonuçları önemli olmakla birlikte, dağıtılmış bir dosya sisteminin performans yeteneklerinin kesin bir ölçüsü olmaktan uzaktır.

SPECsfs2014’ün “netmist” karma iş yükü oluşturucusu bazı durumlarda uygun olabilir, ancak teknik olarak açık kaynaklı bir araç değildir. Bu araç, iozone’un yazarı olan Don Capps tarafından yazılmıştır.

Fio Nasıl Kullanılır?

fio son derece güçlüdür ve iozone’dan farklı olarak geleneksel dağıtımlardan kolayca yüklenir ve Mayıs 2015 itibarıyla –client parametresi yukarı akışında açıklanan giderek daha güçlü dağıtılmış test yeteneklerine sahiptir. Bu modu kullanmak için her iş yükü oluşturucu ana bilgisayarı şunları kullanır:

    fio --server --daemonize=/var/run/fio-svr.pid

Ve güvenlik duvarınızın bunun için 8765 numaralı bağlantı noktasına izin verdiğinden emin olun. Artık, aşağıdaki gibi sözdizimini kullanarak ana bilgisayar kümelerinde testler çalıştırabilirsiniz:

    fio --client=workload-generator.list --output-format=json my-workload.fiojob

Bununla birlikte, fio örneklerini ayrı ana bilgisayarlarda başlatarak, tüm fio örneklerini mümkün olduğunca aynı zamana yakın başlatmaya özen göstererek, iş parçacığı başına aktarım hızını sınırlayarak ve miktar yerine çalıştırma süresini belirterek dağıtılmış test için de kullanabilirsiniz. tüm fio örneklerinin yaklaşık olarak aynı anda bitmesi için. Ardından, anlamlı bir toplu sonuç elde etmek için farklı ana bilgisayarlardan gelen fio sonuçlarını toplayabilirsiniz.

fio ayrıca farklı I/O motorlarına sahiptir, özellikle Huamin Chen, FUSE kullanmadan Gluster performansını test etmek için fio’yu kullanabilmeniz için fio için libgfapi motorunu yazdı.

Dağıtılmış modda fio sınırlamaları:

Smallfile Dağıtılmış G/Ç Karşılaştırması Nasıl Kullanılır?

Smallfile , bir kümenin tamamında çeşitli meta veri yoğun iş yüklerinin performansını hızlı bir şekilde ölçmek için kullanılabilen python tabanlı küçük dosya dağıtılmış bir POSIX iş yükü oluşturucudur. Herhangi bir belirli dosya sistemine veya AFAIK uygulamasına bağımlılığı yoktur. Linux, Windows üzerinde çalışır ve çoğu Unix’te de çalışması gerekir. Büyük dosya iş yüklerinin performansını ölçmek için iozone kıyaslama kullanımını tamamlamayı amaçlamaktadır ve iozone ve Ric Wheeler’ın fs_mark’ından belirli kavramları ödünç almaktadır. Ben England tarafından Mart 2009’da geliştirilmiştir ve şu anda açık kaynaklıdır (Apache Lisansı v2).

Burada, bir ilk oluşturma testinde ortaya konan dosyaların daha sonra sonraki testlerde kullanıldığı tipik bir basit test dizisi verilmiştir. Bu 5’ten çok daha fazla küçük dosya işlemi türü vardır (dokümana bakın), ancak bunlar en yaygın kullanılanlardır.

    SMF="./smallfile_cli.py --top /mnt/glusterfs/smf --host-set h1,h2,h3,h4 --threads 8 --file-size 4 --files 10000 --response-times Y "
    $SMF --operation create
    for s in $SERVERS ; do ssh $h 'echo 3 > /proc/sys/vm/drop_caches' ; done
    $SMF --operation read
    $SMF --operation append
    $SMF --operation rename
    $SMF --operation delete

Iozone Nasıl Kullanılır?

Bu aracın sınırlamaları vardır, ancak -+m seçeneğini (aşağıda) kullanarak dağıtılmış testi iyi yapar.

Tüm kullanım durumlarının otomatik olarak test edilmesi için “-a” seçeneği önerilmez, çünkü:

Tek iş parçacığı testi önemli bir kullanım durumudur, ancak mevcut donanımı tam olarak kullanmak için genellikle çoklu iş parçacığı ve hatta çoklu ana bilgisayar testi yapmanız gerekir.

Verilerin kalıcı depolamaya ulaşması için geçen süreyi ölçmek için “-c -e” seçeneklerini kullanmayı düşünün. “-C” seçeneği, her bir iş parçacığının teste ne kadar katıldığını görmenizi sağlar. “-+n”, yeniden okuma ve yeniden yazma testlerini atlayarak zamandan tasarruf etmenizi sağlar. “-w” seçeneği, iozone’a eriştiği dosyaları silmemesini söyler, böylece sonraki testler bunları kullanabilir. Her testte şu seçenekleri belirtin:

64 KB aktarım boyutu ve 1 GB dosya boyutuyla paylaşılan Gluster bağlama noktası dizinine /mnt/glusterfs ile 8 iş parçacıklı sıralı yazma testi örneği, aktarım hızı hesaplamasındaki dosyaları fsync() ve kapatma() zamanı dahil:

    iozone -w -c -e -i 0 -+n -C -r 64k -s 1g -t 8 -F /mnt/glusterfs/f{0,1,2,3,4,5,6,7,8}.ioz

UYARI: iozone’da rastgele G/Ç testi, rastgele okuması ve ardından tüm dosyayı rastgele yazması gereken iozone kısıtlamasıyla büyük ölçüde kısıtlanmıştır! İstediğimiz bu değil – bunun yerine dosya boyutunun veya sürenin bir kısmı için rastgele okuma/yazma yapmalı ve testin bitmesi için fazla beklemeden diske daha fazla yayılmamıza izin vermelidir. Bu nedenle fio (aşağıda), rastgele G/Ç iş yükleri için tercih edilen test aracıdır.

Dağıtılmış test, iozone yardımcı programının bir gücüdür, ancak bu, “-F” seçeneği yerine “-+m” seçeneğinin kullanılmasını gerektirir. “-+m” seçeneğiyle iletilen yapılandırma dosyası şuna benzeyen bir dizi kayıt içerir:

    hostname   directory   iozone-pathname

Ana bilgisayar adı, iozone’un kullanabileceği bir test sürücüsü makinesinin ana bilgisayar adı veya IP adresi olduğunda, dizin, o ana bilgisayar içinde kullanılacak bir dizinin yol adıdır ve iozone-yol adı, o ana bilgisayarda kullanılacak iozone yürütülebilir dosyasının tam yol adıdır. Her hedef ana bilgisayarın, iozone komutunun çalıştırıldığı ana bilgisayarın ana bilgisayar adını çözebildiğinden emin olun. Tüm hedef ana bilgisayarlar, komutu çalıştıran ana bilgisayardan parolasız ssh erişimine izin vermelidir.

Örneğin: (Burada ip adresim, iozone’un çalıştırıldığı makineyi ifade eder)

    export RSH=ssh
    iozone -+m ioz.cfg -+h my-ip-address -w -c -e -i 0 -+n -C -r 64k -s 1g -t 4

Ve ioz.cfg dosyası bu kayıtları içerir (burada /mnt/glusterfs, her test makinesindeki Gluster bağlama noktasıdır ve test-client-ip, bir istemcinin IP adresidir). Ayrıca, dosyadaki her kaydın IOZone terminolojisinde bir iş parçacığı olduğunu unutmayın. Yukarıdaki örnekte thread sayısını 4 olarak tanımladığımız için tek bir client için 4 tane kaydımız(thread) var.

    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone
    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone
    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone
    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone

Kısıtlama: iozone ayrıcalıklı olmayan bağlantı noktaları kullandığından, bazı/tüm ana bilgisayarlarda iptables’ı geçici olarak kapatmak veya değiştirmek gerekebilir. İkincil makineler, ssh aracılığıyla Birincil makineden parolasız erişimi desteklemelidir.

-+h seçeneğinin belgelenmemiş olduğunu, ancak ikincil ana bilgisayara hangi IP adresinin kullanılacağını söyler, böylece ikincil ana bilgisayarın test sürücüsünün ana bilgisayar adını çözümleyebilmesi gerekmez. my-ip-address, sonuçları ana bilgisayara geri bildirmek için ikincil kişinin bağlanması gereken IP adresidir. Bunun, ana bilgisayarın ana bilgisayar adıyla aynı olması gerekmez.

Tipik olarak, dosyayı yerleştirmek, sunuculara (ve gerekirse istemcilere) önbelleği bırakmak, sıralı okuma testi yapmak, önbelleği bırakmak, istenirse rastgele G/Ç testi yapmak için önce sıralı yazma testini çalıştırırsınız. Yukarıdaki örneği kullanarak:

    export RSH=ssh
    IOZ="iozone -+m ioz.cfg -+h my-ip-address -w -C -c -e -r 64k -+n "
     hosts="`awk '{ print $1 }' ioz.cfg`"
    $IOZ -i 0 -s 1g -t 4`\
    for n in $hosts $servers ; do \
       ssh $n 'sync; echo 1 > /proc/sys/vm/drop_caches' ; done
    $IOZ -i 1 -s 1g -t 4
    for n in $hosts $servers ; do \
       ssh $n 'sync; echo 1 > /proc/sys/vm/drop_caches' ; done
    $IOZ -i 2 -s 1g -t 4

Arabelleğe alınmış G/Ç (varsayılan) ile istemci kullanıyorsanız, önce istemci makinelere, ardından sunucu makinelerine de yukarıda gösterildiği gibi önbelleği bırakın.

paralel-libgfapi

Bu test Gluster performansını libgfapi API kullanarak, FUSE’yi atlayarak uygular – hiçbir bağlama noktası kullanılmaz. Burada mevcut .

Bunu kullanmak için, parallel_gfapi_test.sh komut dosyasındaki komut dosyası parametrelerini düzenlersiniz – bunların tümü “BU SATIRIN ALTINDA DÜZENLENEBİLİR PARAMETRE YOK” yorumunun üzerindedir. Bunlar, Gluster birim adı, o birime hizmet veren bir ana bilgisayar, dosya sayısı vb. gibi şeyleri içerir. Ardından, gfapi_perf_test yürütülebilir dosyasının belirtilen dizindeki istemci makinelere dağıtıldığından emin olun ve ardından komut dosyasını çalıştırın. Komut dosyası, tüm libgfapi iş yükü oluşturucu işlemlerini, hepsi testi aynı anda başlatacak şekilde paralel olarak başlatır. Hepsi tamamlanana kadar bekler ve ardından sonuçları sizin için toplar ve bir araya getirir.

libgfapi süreçlerinin parça başına bir soket tükettiğine dikkat edin, bu nedenle yüksek parça sayısına sahip Gluster hacimlerinde, aynı anda çalışabilen libgfapi işlemlerinin sayısında kısıtlamalar olabilir. Spesifik olarak, her ana bilgisayar yalnızca yaklaşık 30000 eşzamanlı TCP bağlantı noktasını destekleyebilir. “ulimit -n” parametresini ayarlamanız gerekebilir (kalıcı ayar için /etc/security/limits.conf “nofile” parametresine bakın).

Nesne Deposu araçları

COSBench , Intel çalışanları tarafından geliştirildi ve hem Swift hem de S3 iş yükü üretimi için çok kullanışlı.

ssbench , OpenStack Swift araç setinin bir parçasıdır ve iş yükü tanımı dosya formatına sahip komut satırı aracıdır.

İş yoğunluğu

Bir uygulama, bazı dosyaları yazmak kadar basit olabilir veya Gluster’ın üzerinde bir bulut çalıştırmak kadar karmaşık olabilir. Ancak tüm uygulamaların, kullanıcılar farkında olsun ya da olmasın, performans gereksinimleri vardır ve bu gereksinimler karşılanmazsa, sistem bir bütün olarak kullanıcı açısından işlevsel değildir. Uygulamanın zamanının çoğunu Gluster ile yaptığı aktiviteler aşağıda “iş yükü” olarak adlandırılmaktadır. Gluster dosya sistemi için “iş yükü”, uygulama tarafından Gluster’a iletilen dosya sistemi isteklerinden oluşur. İş yüküne bakmanın iki yolu vardır:

Veri vs meta veri

Bu sayfada sık sık “büyük dosya” veya “küçük dosya” iş yüklerine atıfta bulunuyoruz. Ama “büyük dosya” veya “küçük dosya” terimleriyle ne demek istiyoruz? “büyük dosya”, uygulama zamanının çoğunun dosyayı okumak/yazmak için harcandığı iş yüklerini ifade eden, kasten belirsiz ancak açıklayıcı bir terimdir. Bu, uygulamanın zamanının çoğunu dosyayı açmak/kapatmak veya dosyayla ilgili meta verilere erişmek için harcadığı “küçük dosya” iş yükünün aksine. Meta veri “veri hakkında veri” anlamına gelir, bu nedenle dosyanın içeriğinden ziyade dosyanın durumunu tanımlayan bilgidir. Örneğin, bir dosya adı, dizinler ve genişletilmiş öznitelikler gibi bir meta veri türüdür.

Yukarıdan aşağıya iş yükü analizi

Genellikle kullanıcıların size bu konuda yardımcı olabileceği şey budur – örneğin, bir iş yükü bir milyar .mp3 dosyasının alınmasından oluşabilir. Yanıtlanması gereken tipik sorular (yaklaşık olarak):

Bu sorular neden önemli? Örneğin, büyük bir dosya sıralı okuma iş yükünüz varsa, ağ yapılandırması + Gluster ve Linux okuması önemlidir. Küçük bir dosya iş yükünüz varsa, depolama yapılandırması önemlidir vb. İş yükünü temel olarak anlamadığınız sürece Gluster için hangi ayarın uygun olduğunu bilemezsiniz.

Aşağıdan yukarıya analiz

Dosya sisteminin isteklerine hizmet etmesi açısından karmaşık bir uygulama bile çok basit bir iş yüküne sahip olabilir. Uygulamanızın zamanını ne yaparak geçirdiğini bilmiyorsanız, “gluster volume profile” ve “gluster volume top” komutlarını çalıştırarak başlayabilirsiniz. Bu son derece kullanışlı araçlar, hem iş yükünü hem de bu iş yükünün performansını sınırlayan darboğazları anlamanıza yardımcı olacaktır.

TBS: Verileri kullanılabilir forma indirgeyen bu araçlar ve komut dosyaları için belgelere bağlantılar.

Yapılandırma

Bir Gluster sunucusunda, önem sırasına göre burada listelenen 4 temel donanım boyutu vardır:

Ağ Testi için Netperf Nasıl Kullanılır?

Ağ yapılandırmasının, dağıtılmış depolamanın performansı üzerinde büyük bir etkisi vardır, ancak küme yaşam döngüsünün planlama ve kurulum aşamalarında genellikle hak ettiği dikkat gösterilmez. Neyse ki, ağ yapılandırması genellikle ek donanım olmadan önemli ölçüde geliştirilebilir.

Ağ performansını ölçmek için netperf tabanlı bir komut dosyası kullanmayı düşünün.

Bu iki aracın amacı, birden çok ağ bağlantısını paralel olarak kullanarak, dağıtılmış depolamanın neden olduğu istenen trafik düzeyini desteklemek için tüm ağ altyapınızın kapasitesini karakterize etmektir. İkinci komut dosyası, dağıtılmış depolama için muhtemelen en gerçekçi ağ iş yüküdür.

Dağıtılmış depolamayı etkileyen en yaygın iki donanım sorunu, şaşırtıcı olmayan bir şekilde, disk sürücüsü arızaları ve ağ arızalarıdır. Bu hatalardan bazıları, sabit hatalara neden olmaz, bunun yerine performansın düşmesine neden olur. Örneğin, iki fiziksel ağ arabirimi içeren bağlı bir ağ arabirimi ile, fiziksel arabirimlerden biri (NIC/anahtar üzerindeki bağlantı noktası veya kablo) arızalanırsa, bağlı arabirim çalışmaya devam eder, ancak daha az performansa sahip olur (ne kadar daha az? bağlama moduna bağlıdır). Başka bir hata, 10-GbE Ethernet arabiriminin hızı 10-Gbps’ye otomatik olarak ayarlayamaması olabilir – bazen ağ arabirimleri bunun yerine otomatik olarak 1-Gbps’ye geçer. TCP bağlantısı yüksek oranda paket kaybı yaşıyorsa veya doğru ayarlanmazsa, donanım tarafından desteklenen tam ağ hızına ulaşamayabilir.

Öyleyse neden sadece bir tane yerine paralel netperf oturumları çalıştırıyorsunuz? Ağ topolojisi (ana bilgisayarların birbirine bağlanma şekli), özellikle ağ anahtarı ve yönlendirici topolojisi ile ilgili çeşitli ağ performans sorunları vardır ve bunlar yalnızca birkaç ana bilgisayar çifti aynı paylaşılan kaynak üzerinden trafik iletmeye çalıştığında ortaya çıkar. örneğin, raf üstü anahtarları birbirine bağlayan bir ana hat veya arka paneli değiştirmek için yetersiz bant genişliğine sahip blade tabanlı bir anahtar olabilir. Bireysel netperf/iperf oturumları bu sorunları bulamaz, ancak bu komut dosyası bulur.

Bu test, örneğin dağıtılmış bir dosya sistemi aracılığıyla veri akışını simüle etmek için kullanılabilir. 4 Gluster istemcisini simüle etmek istiyorsanız, onları c1’den c4’e kadar arayın, büyük dosyaları 2 sunucu kümesine yazın, s1 ve s2 olarak adlandırın, şu (gönderen, alıcı) çiftlerini belirleyebilirsiniz:

    (c1,s1), (c2, s2), (c3, s1), (c4, s2)

Öte yandan, okumaları simüle etmek istiyorsanız, bu (gönderen, alıcı) çiftlerini kullanabilirsiniz:

    (s1, c1), (s2, c2), (s1, c3), (s2, c4)

Karışık bir okuma-yazma iş yükünü simüle etmek için her iki çift kümesini kullanın:

    (c1,s1), (c2, s2), (c3, s1), (c4, s2), (s1, c1), (s2, c2), (s1, c3), (s2, c4)

Daha karmaşık akışlar, bir küme düğümünün bir proxy sunucusu gibi davrandığı yerel olmayan protokollerin davranışını modelleyebilir; bu, bir sunucu (yerel olmayan protokol için) ve bir istemcidir (yerel protokol için). Örneğin, bu tür protokoller genellikle, ağı tek yönlü giriş/çıkış trafiğinden farklı şekilde zorlayabilen tam çift yönlü trafiği tetikler. Örneğin, bu akış kümesini önceki akışa eklemeyi deneyin:

    (s1, s2),.(s2, s3),.(s3, s4),.(s4, s1)

Komut dosyasının üst kısmındaki yorumlar, giriş sözdizimini açıklar, ancak burada en iyi şekilde nasıl kullanılacağına dair bazı öneriler. Bu komut dosyasını genellikle, test edilen makine grubuna parolasız ssh erişimi olan bir ana düğümden veya test sürücüsünden çalıştırırsınız. Testi çalıştıran ana bilgisayarların birbirlerine ssh erişimine ihtiyacı yoktur – yalnızca ana düğümden parolasız ssh erişimine izin vermeleri gerekir. Komut dosyası kök ayrıcalıklarına dayanmaz, bu nedenle onu kök olmayan bir hesaptan çalıştırabilirsiniz. Doğru hesapta (genellikle \$HOME/.ssh/id_rsa.pub içinde) baş düğümde bir genel anahtar oluşturun ve ardından bu ortak anahtarı, teste katılan her ana bilgisayarda \$HOME/.ssh/authorized_keys öğesine ekleyin.

Göndericileri ve alıcıları, satır başına 1 ana bilgisayar olmak üzere ayrı metin dosyaları kullanarak giriyoruz. Çift için (gönderen[j], alıcı[j]), gönderici dosyasındaki j satırından gönderici[j] ve alıcı dosyasındaki j satırından alıcı[j] alırsınız. Test etmek istediğiniz arabirime karşılık gelen IP adresini/adını kullanmanız ve bu arabirimi kullanarak ana düğümden her ana bilgisayara ssh yapabilmeniz gerekir.

Sonuçlar

Önem sırasına göre değil, 3 temel performans sonucu biçimi vardır:

Tipik olarak aktarım hızı sonuçları en çok dikkati çeker, ancak dağıtılmış depolama ortamında ulaşılması en zor hedef aktarım hızı değil, SÜREKLİ DÜŞÜK YANIT SÜRESİ olabilir.

Yanıt süresinin o kadar önemli olmadığı etkileşimli olmayan iş yükleri olsa da, bir kullanıcının dosya sistemiyle doğrudan etkileşime girmesi gereken her durumda yanıt süresine dikkat etmelisiniz. Dosya sistemini mutlak en yüksek verimi elde edecek şekilde ayarlamak, yüksek yanıt süresi nedeniyle kullanılamaz olan bir dosya sistemiyle sonuçlanabilir. Bir kıyaslama durumunda değilseniz, iyi bir çıktı ve yanıt süresi dengesi elde etmek istersiniz. Tipik olarak etkileşimli bir kullanıcı, çoğu yanıt süresi bundan çok daha düşük olmak üzere, her zaman 5 saniyenin altında bir yanıt süresi görmek ister. Yanıt sürelerini kontrol altında tutmak için (sistem yönetimi dahil!), herhangi bir donanım bileşeninin maksimum kullanımda çalışmasını istemezsiniz, tipik olarak %60-80 kullanım, iyi bir tepe kullanım hedefidir. Öte yandan, donanım israfını önlemek için,

WordPress › Hata

Sitenizde ciddi bir sorun çıktı.

WordPress sorunlarını gidermek hakkında ayrıntılı bilgi alın.