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.
Şimdi ortak anahtarı ssh-copy-id komutunu kullanarak bağımlı sunucuya kopyalayın
ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
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
Ö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] ~]#
[ [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'
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,
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 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.
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;
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 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
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.
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
veya
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.
komutu ile dosyanın içerisine girerek uygun bir yere
yazıyoruz. Akabinde shell ekranımızı yeniden başlatıp
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:
Bunlara ek olarak bir de “kubectl” komutu yerine “k” komutunu kullanabilmek için aşağıdaki komutlar ile bir alias tanımlayabiliriz.
İş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.
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.
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.
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.
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.
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.
Ö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-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
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'
Güncellemek için;
helm upgrade --namespace monitoring p8s-stack prometheus-community/kube-prometheus-stack -f prometheus-stack/values.yaml --version="${chartVersion}"
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]
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`
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]
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`
fake kubeproxy fail alert
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
logda many-to-many hatası
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.
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.
Bu bölüme geçmeden önce bu bölümün daha iyi anlaşılması için sizlere bir örnek vermek istiyorum.
Bu departmanda ürünlerimizi ürettiğimiz makinelerimiz var her makinenin başında ise bir ustabaşı duruyor ve o makinenin kontrolünden sorumlu o makinede ne üretilecekse yönetim kısmından ustabaşına bildiriliyor ustabaşı ise bu üretilecek ürünü üretecek işçiyi getirip bu makinede çalıştırmaya başlıyor.
Yani ustabaşının tüm görevi işçileri ilgili makinelerle yerleştirmek ve durumlarını gözlemek. Ustabaşının hemen yanında ise lojistikten sorumlu bir görevli duruyor.
Bu görevlinin görevi ise o makinelere dışarıdan erişilmesini işçilerin birbirleriyle haberleşmesini sağlıyor. Şimdi şirketimizin yönetim kısmına geçelim.
Şirkete adım attığımız an bizleri kapıda bir güvenlik ve danışma karşılıyor olsun.
Şirket içinden veya şirket dışından gelen tüm iletişim bu danışmadan geçmek zorundaymış gibi hayal edelim.
Danışmanın ana görevi gelen tüm istekleri almak isteği yapan birimin istediği şeye yetkisinin olup olmadığını kontrol etmek ve eğer yetkisi varsa isteği kayıt altına almak yani danışma şirket içi iletişimin kalbi konumunda.
Tekrar ediyorum şirket içerisinden veya dışarıdan her türlü iletişim buradan geçmek zorunda. Danışmanın tam arkasında ise bir arşiv panosu durduğunu hayal edelim.
Danışma gelen bütün istekleri kontrol ettikten sonra bu panoda kayıt altına alıyor kısacası şirketle alakalı tüm bilgiler mevcutta ne kadar üretim yapıldığı kaç kişinin çalıştığı kaç makinenin olduğu aklımıza şirketle alakalı gelebilecek tüm bilgiler burada saklanıyor.
Şirketimizde bir diğer birimde üretim planlama birimi az önce bahsettiğim panoyu danışma ve güvenliğin izniyle sürekli izliyor eğer kayıtlarda yeni bir ürünün üretilmesine yönelik bir talimat görürse hemen bu talimatı alıyor sonrasında tüm makinelere bakıyor içlerinden bu talimattaki ürünü üretebilecek özellikte olanı seçiyor bunlardan en uygununu belirliyor ve o işe uygun işçinin o makinede üretilmesini sağlıyor.
Şirketimizde bulunan son birim ise vardiya amirliği. Burada 4 farklı insan çalışıyor bunların her biri aynı işi yapıyor ama hepsinin sorumlu olduğu ayrı bir yer var.
Bir kişi sürekli panoyu gözlerken diğer bir kişi ise sorumlu olduğu yapıları kontrol ediyor.
Yani şöyle anlatayım işçilerden sorumlu olan kişi sürekli panoyu gözlüyor bir makinede 10 işçi çalışacak bilgisi panoda yazıyor ise üretim kısmını gözlüyor ve 10 işçinin çalışıp çalışmadığını kontrol ediyor eğer işçilerden birisi bir nedenle makinenin başından ayrılırsa hemen bunu tespit ediyor ve hemen bunu düzeltmek için devreye giriyor ve o makinenin başına bir işçi gönderiyor yani 10 işçi çalışacak hale getiriyor.
Yani her birinin bir görevi var kimi makineleri gözlerken bir diğeri panoyu gözlüyor ama aslında hepsinin yaptığı iş aynı hepsi temelde panoda yazılanla mevcut durum örtüşüyor mu bunu kontrol ediyor ve aynı değilse aynı olması için gerekli düzenlemeleri yapıyorlar.
Şimdi bu anlattıklarımı bir bütün halinde ele alalım. Şirketimizin bağlı olduğu bir genel merkez olduğunu düşünelim ve bu genel merkezden şirkete yeni bir üründen 2 adet üretilmesi için talimat geldiğini varsayalım.Şirkete dışarıdan veya içeriden gelen tüm iletişimin güvenlik ve danışmadan geçmesi gerektiğini biliyoruz. Danışma bu talimatı alıyor talimatı gönderen kişinin gerçekten o kişi olup olmadığını kontrol ediyor.Sonrasında talimata bakıyor talimatı gönderen kişinin talimatta yazılanları isteme yetkisi olup olmadığını kontrol ediyor.
Eğer bu adımlar başarılıysa danışma bu isteği panoya yazıyor. Üretim planlamanın danışmadan izin alarak panoyu sürekli gözlemlediğini söylemiştik. Panoya yazılan yeni talimatı görüp 2 adet yeni ürün üretilmesi gerektiğini görüyorlar. Hemen bu ürünlerin üretilebileceği makineleri tespit ediyorlar. Ardından bu tespitlerine en uygun makineyi seçip panoya yazıyorlar.5 ve 10 numaralı makinelerde 2 işçi çalışmalı. Danışma bu bilgiyi ilgili makinelerin usta başlarına bildiriyor.
Her makinenin ustabaşı belirlenen özelliklerde ürünün üretilebilmesi için işçileri makine başına koyuyor ve çalıştırmaya başlıyor. Ardından işçilerin çalışmaya başladığını ve diğer bilgileri resepsiyona bildiriyor ve panoya ekliyorlar.Bu sırada lojistikten sorumlu görevliler bu işçilerin iletişimlerini ve koordinasyonlarını sağlamaya başlıyorlar.
Ardından vardiya amirliği devreye giriyor onlarda resepsiyondan aldıkları izin ile panoyu gözlüyorlar her bir vardiya amirliği görevlisi sorumlu olduğu alanlarla ilgili mevcut durumları ve olması gereken durumları panodan kontrol ediyorlar.Bu ikisi arasında fark oluşursa bu farkı düzeltmek için gerekli işlemleri yapıyorlar.
Tüm bunlar belirli düzen içerisinde efektif şekilde çalışıyor.Yani istediğimiz ürünü üreten bir şirket var ama bu şirket dışarıdan tekil bir yapı gibi gözükse de aslında birçok alt komponentin bir arada uyum içerisinde çalışması neticesinde oluşuyorlar.
Yukarıda verdiğim örnekten de tahmin edeceğiniz üzere aslında bütün bunlar bir kubernetes komponentini temsil ediyor.
yönetim komponentlerini temsil ediyor.
üretim komponentlerini temsil ediyor.Şimdi bu komponentleri daha yakından tanıyalım.
- Node Controller
- Job Controller
- Service Account & Token Controller
- Endpoints Controller
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:
İ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şturmayı çalıştırmak için,
/var/run/gluster/io-stats-pre.txt
Bu , 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.
Ç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.
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 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 , 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
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.
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).
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.
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:
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.
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.
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.
Bir Gluster sunucusunda, önem sırasına göre burada listelenen 4 temel donanım boyutu vardı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.
Ö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,