Proxmox cluster ortamında bazı node’lar GUI üzerinde “Unknown” durumuna düşebilir. Bu durumda:

• Node çalışıyor olabilir (SSH erişilebilir)
• HA aktif görünür
• Ancak GUI ve API tarafında node health okunamaz

Aşağıdaki gibi görünür:

Root Cause (En Yaygın Sebep)

Bu durum genellikle:

• pvestatd servisinin kilitlenmesi
• PID lock dosyasının bozulması
• Servisin zombie durumda kalması

nedenleriyle oluşur.

Troubleshooting Adımları

1️⃣ Servis Loglarını Kontrol Et

journalctl -xeu pvestatd.service

Bakılacak şeyler:

• timeout
• lock hataları
• stuck process

2️⃣ Process Kontrolü

ps aux | grep pvestatd

3️⃣ Port / File Lock Kontrolü

lsof | grep pvestatd

veya

fuser /var/run/pvestatd.pid.lock

Burada PID lock kullanan process varsa problem buradadır.

Çözüm (Restart ATMADAN)

1️⃣ Problemli Process’i Öldür

kill -9 <PID>

2️⃣ Servisi Yeniden Başlat

systemctl restart pvestatd

3️⃣ Durumu Kontrol Et

systemctl status pvestatd

ve GUI’den node durumunu kontrol et.

✅ Beklenen Sonuç

• Node status → Online
• Question mark → kaybolur
• Metrics → tekrar akmaya başlar

Sonuç

Bu problem reboot atmadan %95 çözülür ve Proxmox ortamlarında oldukça yaygındır.
Özellikle büyük cluster ortamlarda daha sık görülür.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox Node Status “Unknown” Problemi appeared first on BURAK AKTAŞ.

Proxmox HA ortamında bir node’u bakım moduna almak:

Node’u HA için geçici olarak devre dışı bırakır.
Üzerindeki HA VM’leri otomatik olarak diğer node’lara taşır.

Yani bakım yapacağın node boşaltılır, servis kesintisi olmadan işlem yaparsın.

Önemli Fark (VMware ile Karşılaştırma)

VMware’de olduğu gibi GUI üzerinden maintenance mode göremezsin / yönetemezsin.

Proxmox’ta bu işlem sadece CLI üzerinden yapılır.

Bakım Moduna Alma (Enable)

ha-manager crm-command node-maintenance enable NODENAME

Ne olur ?

• HA sistemi node’u unavailable olarak işaretler.
• Üzerindeki HA VM’ler diğer node’lara migrate edilir.
• Node boşalır ve bakım için hazır hale gelir.

Bakım Modundan Çıkarma (Disable)

Bakım bittikten sonra node’u tekrar cluster’a almak için:

ha-manager crm-command node-maintenance disable NODENAME

Ne olur ?

• Node tekrar available olur.
• HA sistemi isterse VM’leri geri taşıyabilir.

Önemli Notlar (Kritik)

1. VM’ler anında gitmez

• Komutu verdikten sonra migration başlar.
• Node tamamen boşalana kadar beklemelisin.

2. Reboot atsan bile maintenance mode kalır

• Node restart olunca otomatik çıkmaz.
• Mutlaka disable etmen gerekir.

3. Her node’dan çalıştırabilirsin

• Komutu sadece ilgili node’da değil.
• Cluster’daki herhangi bir node’dan çalıştırabilirsin.

Proxmox HA ortamında bakım yaparken:

❌ Direkt reboot/shutdown yapma
✅ Önce maintenance mode kullan

Bu, production ortamda servis kesintisini önleyen en kritik adımdır. 👍

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox HA Maintenance Mode appeared first on BURAK AKTAŞ.

If you are configuring settings specific to a cluster, ensure that the same configurations are applied across all nodes in the cluster.

1. Checking for iscsi Initiator

Before proceeding, ensure that the iSCSI Initiator is already installed on your Proxmox system. You can verify its presence by checking the following directory:

/etc/iscsi/...

If it is not installed (typically, it is included if you installed Proxmox using the PVE.iso), you can install it using the following command:

apt-get install open-iscsi

2. Verifying the iSCSI Initiator Name

To begin, I confirmed the unique iSCSI Initiator Name on the Proxmox server. This step ensures proper communication between Proxmox and Pure Storage. The command used was:

cat /etc/iscsi/initiatorname.iscsi

The output displayed the InitiatorName, which is critical for iSCSI communication.

3. Creating a New Host in Pure Storage

In the Pure Storage management interface, I created a new host named “pve-01” to serve as the connection point for Proxmox VE.

4. Configuring the iSCSI IQNs

After creating the host, I configured its iSCSI IQNs to enable communication with Proxmox. The IQN value added was consistent with the Proxmox server’s initiator details.

5. Editing the iSCSI Configuration

The /etc/iscsi/iscsid.conf file was modified to set the session startup mode to automatic and configure session timeouts for stability. The relevant parameters edited included:

node.startup = automatic
node.session.timeo.replacement_timeout = 15

6. Restarting and Verifying iSCSI Service

I restarted the iscsid.service to apply the configuration changes and confirmed its active status using:

systemctl restart iscsid.service
systemctl status iscsid.service

7. Adding iSCSI Storage in Proxmox VE

Using the Proxmox VE interface, I added iSCSI storage under the “Datacenter” and configured it with portal addresses, target IQN, and nodes.

Volume usage / RDM blocking

If you want to use LVM on top of iSCSI, it make sense to set content none. That way it is not possible to create VMs using iSCSI LUNs directly. The iSCSI protocol does not define an interface to allocate or delete data. Instead, that needs to be done on the target side and is vendor specific. The target simply exports them as numbered LUNs. So Proxmox VE iSCSI volume names just encodes some information about the LUN as seen by the linux kernel. iSCSI is a block level type storage, and provides no management interface. So it is usually best to export one big LUN, and setup LVM on top of that LUN. You can then use the LVM plugin to manage the storage on that iSCSI LUN.

8. Scanning for iSCSI Targets

To ensure the iSCSI target was reachable, I used the pvesm scan iscsi command in the terminal. The scan successfully detected the Pure Storage target and its portals.

9. Configuring Multipath

I then set up multipath to provide fault tolerance and enhanced performance. The /etc/multipath/multipath.conf file was edited to include the Pure Storage device’s WWID and an alias:

multipath -a

10. Restarting Multipath Services

I restarted the Multipath service and verified it was running correctly:

systemctl restart multipath-tools.service
systemctl status multipath-tools.service

11. Verifying Multipath Devices

Using the multipath -ll command, I validated that the Pure Storage device paths were active and properly configured.

12. Adding LVM Storage in Proxmox

Next, I configured an LVM storage unit in Proxmox VE based on the connected iSCSI storage. The details included volume groups and allowed content types (disk images and containers).

13. Editing LVM Storage Configuration

I fine-tuned the LVM storage configuration, enabling options such as “Shared” and linking it to all nodes for seamless access across the cluster.

14. Final Verification

Lastly, I verified the storage integration in the Proxmox interface, ensuring the added LVM storage unit was accessible and operational.

Potential Issues

If you are adding your LUN to a cluster, it is likely that you will need to restart all nodes except the primary node. Otherwise, you may see a question mark icon above the iSCSI and LVM options in the Server View and realize that these nodes are not connected to the target at all. Alternatively, you can restart the service using the following command:

systemctl restart open-iscsi.service

Result

This detailed step-by-step configuration enabled seamless integration between Proxmox VE and Pure Storage using iSCSI and LVM. Each step was executed to ensure performance, reliability, and optimal storage utilization in my virtualized environment.

To verify redundancy, I performed a test by disabling the ports of Pure Storage controllers ct0 and ct1 sequentially. During the test, I verified that the network and IQN connections remained intact despite the port shutdowns. The result showed successful redundancy and stability of the configuration.

Source: Proxmox ISCSI Multipath

The post Proxmox VE with Pure Storage using iSCSI and LVM appeared first on BURAK AKTAŞ.

Proxmox ortamına giriş yapıyoruz ve en tepeden Datacenter’ı seçip Realms sekmesine gidiyoruz.

Burada LDAP Server‘ı seçip, önce General tabını dolduruyoruz sonrasında Sync Options tabını dolduruyoruz.

Sync Options tabında bizden AD üzerinde bir adet read yetkili servis user istiyor onu oluşturup ilgili alana ekliyoruz.

Bu adımlar tamamlandıktan sonra yetki verme kısmına geçiyoruz. Proxmox’un çekmesini istediğimiz OU’yu veriyoruz ve AD tarafında group oluşturuyoruz. Yetkilendirmeyi yaparken group olarak yapıyoruz.

Group yetkilendirmesi tamamlandıktan sonra kullanıcıyı Enable ediyoruz.

Son olarak Proxmox’un AD üzerinden değişiklikleri çekmesi için bir Realm Sync Job oluşturuyoruz.

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox VE AD LDAP Yapılandırması appeared first on BURAK AKTAŞ.

Öncelikle unix bir işletim sistemine database için Influxdb2 ve monitör ekranımız için de Grafana ürünlerini kuruyoruz.

InfluxDB2 Kurulumu

• apt install gpg apt-transport-https -y
• wget -q https://repos.influxdata.com/influxdata-archive_compat.key
• echo ‘393e8779c89ac8d958f81f942f9ad7fb82a25e133faddaf92e15b16e6ac9ce4c influxdata-archive_compat.key’ | sha256sum -c
• cat influxdata-archive_compat.key | gpg –dearmor > /etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg
• echo ‘deb [signed-by=/etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg] https://repos.influxdata.com/debian stable main’ > /etc/apt/sources.list.d/influxdata.list
• apt update && apt install influxdb2 -y
• systemctl enable –now influxdb
• systemctl status influxdb

Grafana Kurulumu

• wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key
• echo “deb [signed-by=/usr/share/keyrings/grafana.key] https://apt.grafana.com stable main” > /etc/apt/sources.list.d/grafana.list
• apt update && apt install grafana -y
• systemctl enable –now grafana-server
• systemctl status grafana

Kurulum işlemlerimiz bittikten sonra öncelikle influxdb2 yapılandırmasından başlıyoruz.

influxdb2‘ye kurmuş olduğumuz makinenin ip’si üzerinden 8086 portundan erişiyoruz.

http://ip_adres:8086/

Karşımıza gelen ilk ekranda bir kullanıcı adı ve şifre tanımlıyoruz. Default olacak bir bucket oluşturuyoruz. Oluşturduğumuz bu bucket’ın bir önemi yok adını default verip geçebilirizde.

Yapılandırma için Quick Start adımından devam ediyoruz.

Bir bucket oluşturuyoruz. Bu bucket sadece proxmox sunucularının izlenmesi için kullanılacağından adını proxmox olarak veriyoruz.

Bir api token’a ihtiyacımız var. Bu api token ProxmoxVE sunucularından veriyi alıp influxdb2‘ye yazacak. Bunu oluşturuken de bir önceki adımda oluşturmuş olduğumuz proxmox bucket üzerinde read write yetkisi veriyoruz.

Oluşturmuş olduğumuz bucket’ın api token’nini ProxmoxVE ortamına tanıtmamız gerekiyor. ProxmoxVE ortamına gidip Datacenter seviyesinde metric server’a ekliyoruz. Burada işimizi kolaylaştıran bir durum var. ProxmoxVE influxdb2 support etmekte, bu yüzden bizde kurulumu influxdb2 üzerinden yaptık.

influxdb2 tarafında işimiz tamamlandı. Buradan sonra Grafana üzerinde influxdb2 tanımlarımızı yapıyor olacağız.

En başta kurmuş olduğumuz Grafana ürününe ilgili makinenin ip’si üzerinden 3000 portundan erişiyoruz.

http://ip_adres:3000/

Sonra bir datasource eklemek için ilgili sekmeyi seçiyoruz ve influxdb datasource’u seçiyoruz.

Bu adımda tekrardan influxdb2 üzerinden bir api token daha oluşturuyoruz. Bu api token’de bize influxdb2 üzerindeki veriyi Grafana‘ya yansıtmamıza yarayacak. Bunun içinde grafana isimli bir api token oluşturup bunada ilgili db üzerinde read yetkisi veriyoruz.

Datasource eklenmesi için ihtiyacımız olan bölümleri doldurup Save & Test diyerek kaydı kapatıyoruz.

Buradan sonra artık ihtiyacımız olan dashboard’ları eklemekte. Community’ler ProxmoxVE‘nin monitörlenmesi için güzel ekranlar oluşturmuşlar. Bunları Grafana‘nın dashboard sayfasından bulup ekledik ama kendimiz de custom ekranlar yapabiliriz.

Grafana‘nın sayfasına gidip ilgili dashboardların ID’lerini kopyalıyoruz.

Kopyalamış olduğumuz ID’yi artık Grafana‘ya ekliyoruz.

Ortamımız hazır güncel bir şekilde metrikleri çekmektedir.

Kaynaklar:
https://www.apalrd.net/posts/2023/pve_influx/
https://grafana.com/grafana/dashboards/15356-proxmox-cluster-flux/

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Monitoring Proxmox VE with InfluxDB and Grafana appeared first on BURAK AKTAŞ.

Proxmox ürün ailesi Linux çekirdeği üzerinde çalışmaktadır. Proxmox, Debian tabanlı bir dağıtımdır ve Debian’ın kararlı sürümlerinde kullanılan Linux çekirdeği versiyonlarını kullanır. Genellikle, Proxmox, uzun vadeli destek (LTS) sunan ve güvenilirlik açısından test edilmiş Linux çekirdeği sürümlerini tercih eder. Proxmox’un belirli bir sürümü, belirli bir Linux çekirdeği versiyonuyla gelir, ancak kullanıcılar, ihtiyaçlarına göre çekirdek versiyonlarını değiştirebilir veya güncelleyebilirler.

Debian sürümlerini aşağıdaki link üzerinden kontrol edebilirsiniz.

Debian Releases

Ben ürünü 2.4’den 3.2’ye upgrade ederken debian sürümünüde güncellemiş olacağım. 2.4 version Debian bullseye sürümünde çalışmakta olup 3.2 version Debian bookworm sürümde çalışmaktadır. Bu bağlamda upgrade yapmadan önce sürümleri ve uyumluluklarını kontrol edip doğru repo’yu tanımlamamız gerekiyor.

Proxmox Backup Server version kontrolünü cli üzerinden yapmak isterseniz aşağıdaki komut size yardımcı olacaktır.

#proxmox-backup-manager versions

Proxmox Backup Server’ı 3.2 version’a upgrade edeceğiniz zaman Proxmox VE’nin de version 8 olması gerekiyor. Buna dikkat etmenizi tavsiye ederim.

En kötü durumuda düşünerek ilgili tüm yapılandırmaların kurtarılabilmesini sağlamak için /etc/proxmox-backup dosyasının yedeğini alın.

tar czf “pbs2-etc-backup-$(date -I).tar.gz” -C “/etc” “proxmox-backup”

Son olarak root bağlantı noktasında 5 GB boş alan olduğundan emin olun (df -h /) ve opsiyonel olarak backup server’ı bakım moduna alın. Bakım moduna aldığınızda backup storage read-only olacak bu sayede upgrade sırasında bir backup job çalışmayacak.

Bakım moduna ister gui, isterseniz cli üzerinden alabilirsiniz.

• enable read-only mode (replace DATASTORE-ID with actual value)
• proxmox-backup-manager datastore update DATASTORE-ID –maintenance-mode read-only
• disable read-only mode
• proxmox-backup-manager datastore update DATASTORE-ID –delete maintenance-mode

Artık upgrade’e başlayabiliriz. Aşağıdaki resimde görüldüğü üzere Debian bullseye tanımlı biz bunu Debian bookworm‘e çevireceğiz.

Öncelikle /etc/apt/source.list ve /etc/apt/sources.list.d/pbs-enterprise.list altındaki debian bullseye sürümünü debian bookworm olarak değiştiriyoruz.

İlgili source list’leri değiştirdikten sonra update package database’i güncelliyoruz.

Ben upgrade’i gui üzerinden yapıyorum ama dilerseniz cli üzerinden de ilgili adımları takip ederek güncelleme yapabilirsiniz.

Upgrade dedikten sonra karşımıza console ekranı gelecek ve buradan upgrade’i takip edebileceksiniz.

Upgrade başarıyla sonuçlanırsa, yeni çekirdeği etkinleştirmek için sistemi yeniden başlatabilirsiniz.

#systemctl reboot

Reboot dönüşü sonrasında arayüzden Proxmox Backup Server‘ ın 3.2 sürümüne geçtiğini görüyoruz.

Dilerseniz cli üzerinden de kontrol edebilirsiniz.

#proxmox-backup-manager versions

Yükseltmeden önce bakım modunu etkinleştirdiyseniz, tekrar devre dışı bırakmayı unutmayın. Bunu web kullanıcı arayüzü üzerinden veya komut satırı arayüzünü (CLI) kullanarak yapabilirsiniz.

• disable read-only mode (replace DATASTORE-ID with actual value)
• proxmox-backup-manager datastore update DATASTORE-ID –delete maintenance-mode

Kaynak: Upgrade From 2 to 3

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox Backup Server Upgrade 2.4 to 3.2 appeared first on BURAK AKTAŞ.

İlk olarak Proxmox Backup Server‘ı kurmak için ilgili link’den iso’muzu download ediyoruz.

https://www.proxmox.com/en/downloads/proxmox-backup-server/iso

Proxmox Backup Server iso dosyası kurulum yapılacak sunucuya mount edildikten sonra “Welcome to Proxmox Backup Server” ekranında ”Install Proxmox Backup Server” tıklanır.

”End User License Aggrement (EULA)” ekranında ”I agree“ tıklanarak devam edilir.

Proxmox Backup Server dosyalarının kurulumunun yapılacağı disk için ”Target Harddisk” kısmında disk seçilerek ”Next“ tıklanır.

Varsayılan dosya sistemi ext4‘tür. Ext4 veya xfs seçildiğinde Logical Volume Manager (LVM) kullanılır.

İşletim sistemi sürücüsü için yaygın bir uygulama controller arabirimini kullanarak RAID-1 array kullanmaktır. Bu disklerden biri arızalanırsa disk yedekliliği sağlar. Aynı yedeklilik düzeyi, ZFS gibi software-RAID array‘i kullanılarak da elde edilebilir. Fakat tavsiyem Proxmox Backup Server‘ın kurulum yapılacağı OS diskleri fiziksel raid yapılmalıdır.

Proxmox Backup Server kurulumun hemen başında işletim sistemi diski için ZFS tabanlı array seçme seçenekleri sunmaktadır.

ZFS tabanlı seçenekler için ”Options“ tıklanır filesystem’deki seçenekler aşağıdaki gibidir.

Benim test amaçlı kurmuş olduğum sunucular üzerinde raid controller olmadığından dolayı bizde zfs (RAID1) yaparak işletim sistemi Proxmox Backup Server‘ı kuracağız. Ekran görüntüsünde de görüldüğü üzere ilgili diskleri seçiyoruz ve software-RAID yapıyoruz.

”Location and Time Zone Selection” ekranında Country, Time Zone ve Keyboard Layout seçilerek ”Next“ tıklanır.

”Administration Password and E-mail Address” ekranında Password, Confirm ve e-mail kısımları doldurularak ”Next“ tıklanır.

”Management Network Configuration“ ekranında Proxmox VE node’un yönetim arayüzüne erişimin yapılacağı network kartının seçimi için ”Management Interface“ seçildikten sonra Hostname (FQDN), IP Address, Netmask, Gateway ve DNS Server bilgileri girilerek ”Next“ tıklanır.

Bu ekranda yanlızca 1 adet DNS Server IP adresi girilmektedir. 1’den fazla dns tanımını kurulum sonrasında GUI üzerinden veya cli ile /etc/resolv.conf dosyasından ekleyebiliyoruz.

”Summary“ ekranında bir önceki ekranlarda girilen bilgiler kontrol edilerek kurulumun başlaması için ”Install” tıklanır.

”Installation Successful!“ Ekranında Kurulumun tamamlandığı bilgisi ve erişimin nasıl yapılması gerektiği ile ilgili bilgiler görülmektedir ”Reboot” tıklanır.

Reboot işlemide tamamladıktan sonra erişim sağlamak için tarayıcınıza kurulum sırasında verilen IP adresi ile aşağıdaki şekilde erişebilirsiniz.

https://ip_address:8007

“User name“ kısmına “root” ve kurulum esnasında verdiğimiz şifreyi ”Password“ kısmına yazarak ”Login“ tıklandıktan sonra aşağıdaki gibi management arayüzüne erişmiş oluyoruz.

Kurulum görüldüğü üzere çok hızlı ve kolay tamamlandı. Burdan sonra şirket politikanıza ve sistem alt yapınıza uygun olarak yapılandırmaları yapabilirsiniz.

Ben kurulumda basit tek nic bridge mode bir kurulum yaptım, burada network ekipleriniz ile istişare ederek Management Config de çift nic bond mimarisi de yapabilirsiniz.

Kurulum sırasında bizden bir adet dns istedi yapınızda 1 den fazla dns server var ise bunları GUI üzerinden veya CLI yardımı ile nano /etc/resolv.conf dosyası içinden tanımlayabilirsiniz.

Sonrasında nano etc/chrony/chrony.conf config dosyasını düzenleyerek kullanmak istediniz ntp’ lerinizi tanımlayabilirsiniz.

Burdan sonra backup sunucumuza backuplarımızı tutacağımız bir Storage/Disk eklememiz gerekiyor. Ben test amaçlı yaptığım için ilgili sunucuya 500 GB’lık bir disk ekleyip bunu da datastore olarak tanımladım.

Proxmox Backup Server üzerinde oluşturmuş olduğumuz backup datastore’u daha sonrasında Proxmox VE ortamımıza tanıtmamız gerekiyor. Bunun için öncelikle backup server üzerinden Connection Information menüsünden Fingerprint‘i alıyoruz.

Ve son olarak Proxmox VE ortamımıza backup server’ın backup datastore’unu ekliyoruz.

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox Backup Server 2.4 Kurulumu appeared first on BURAK AKTAŞ.

Öncelikle Proxmox VE üzerine Ceph kurulumumuzu ve ayarlarımızı yapmadan önce Ceph’in yapısından ve mimarisinden başlayalım.
Ceph kurulumlarında sıkca duyacağımız PG (Placement Group), OSD (Object Storage Daemon), RBD (Rados Block Device), Ceph MON ve Ceph MGR terimlerini inceleyelim.

Ceph Mimarisi

Ceph nesne tabanlı ve blok depolama ile dosya sistemi türündeki depolama ortamlarının tamamını bir arada sunan ve bu amaçla 5 temel bileşenden oluşan açık kaynak kodlu bir depolama çözümüdür. Bu 5 bileşen aşağıda açıklanmıştır:

• Ceph OSD (Object Storage Daemon): OSD bileşenleri veriyi nesne halinde tutmakla yükümlüdür. Verinin kopyalar halinde (replikasyon) tutulmasını yönetir. Disk ekleme/çıkarma işlemleri sonrasında verinin depolama ortamı üzerinde yeniden yapılandırılarak gerekli kopyaların oluşturulmasını ve diskler üzerinde dengeli olarak dağıtılmasını sağlar. Ayrıca monitör sunucularına disklerin durumu ile ilgili bilgi sağlar. Önerilen yapıda her disk için ayrı bir OSD kullanılması önemli konulardan birisidir.
• Ceph MON (Monitor): Monitör bileşenleri tüm depolama ortamının sağlıklı çalışmasını takip amacıyla haritasını tutar. MAP ismi verilen bu haritalar arasında OSD Map, Monitor Map, PG Map ve CRUSH Map bulunur. Monitör bileşenleri diğer tüm bileşenlerden durum bilgilerini alarak haritayı çıkarır ve bunu diğer monitör ve OSD bileşenleri ile paylaşır. Ceph istemcileri bir okuma veya yazma yapacağı zaman yazacağı OSD ve PG’leri belirledikten sonra bu OSD’lerin çalışır durumda olup olmadığına bakar. İlk belirlenen erişilebilir durumda değilse duruma göre 2. veya 3. OSD kullanılır. Burada belirlenen OSD sayısı replikasyon sayısına bağlıdır.
• Ceph RGW (Rados Gateway): RGW, Ceph’in doğrudan nesne tabanlı depolama ortamına erişmeye olanak veren API servisini sağlayan bileşendir. Bu API Amazon S3 ve OpenStack Swift API ile uyumludur.
• Ceph RBD (Rados Block Device): RBD, Ceph’in nesne tabanlı depolama altyapısı üzerinde çalışan ve sanal sunucular, fiziksel sunucular ve diğer istemcilere blok tabanlı depolama sağlayan katmanıdır. OpenStack ve CloudStack desteği bulunur. Ticari çözümlerin sunduğu snapshot, thin-provisioning ve compression gibi özellikleri destekler.
• Ceph FS (File System): Ceph’in nesne tabanlı depolama altyapısını kullanarak istemcilere POSIX uyumlu dosya sistemi vermesini sağlayan katmanıdır. Linux kernel üzerinde CephFS mount etmek üzere hali hazırda destek bulunduğu gibi alternatif olarak FUSE kullanılarak da mount işlemi yapılabilir. Diğer bileşenlerin aksine CephFS çalışmak için bir metadata sunucusuna ihtiyaç duyar.

Aşağıdaki resimde bu bileşenler gösterilmekte olup monitör sunucuları ve OSD sunucuları ile eğer ihtiyaç duyuluyorsa RGW sunucuları ve metadata sunucuları eklenerek aşağıdaki servisler sağlanabilir.

OSD katmanını biraz daha anlaşılabilir hale getirmek için aşağıdaki resimdeki yapıya dikkat çekilebilir. Depolamanın yapıldığı OSD sunucuları üzerinde işletim sisteminin çalıştığı bir disk ya da disk grubu bulunur. Bu resmin en solunda bulunan ilk sutünda görülmektedir. Alt katmandaki disk ext3, ext4, xfs gibi bir dosya sistemi ile formatlanarak üzerine işletim sistemi kurulur. Bu tüm sunuculardaki klasik kullanım şeklidir. Yanındaki sütunda sarı renk ile gösterilen journal ise OSD servislerinde çalışan mekanik disklere (SAS, SATA veya NL-SAS gibi) önbellek (cache) olarak bağlanmak üzere tasarlanan ve SSD üzerinde çalışan bir yapıdır. SSD disklerin yüksek yazma hızı ve IOPS performansından faydalanılarak yapılan yazma isteklerini karşılayarak sıralı (sequential) hale getirir. Bu disk üzerinde belirlenen süre boyunca önbelleklenen veri sıralı halde daha hızlı bir şekilde diske yazılır, böylece okunurken de sıralı biçimde daha hızlı okunur. OSD servislerine bağlı mekanik diskler ise resmin sağında yer alan ve kesikli çizgi ile çevrelenen alanda gösterilmektedir. Burada da diskler ext4, xfs veya btrfs gibi dosya sistemi ile formatlanarak OSD servislerine bağlanır. OSD servisi veriyi sunucu üzerine OSD servisleri ile mount edilen bu disklere nesneler halinde yazar.

Ceph Üzerinde Veri Yerleşimi

Ceph üzerindeki veri yerleşimini anlamak için önce Ceph tarafından kullanılan bazı temel yapı taşlarını anlamak gerekmektedir. Bunlardan bu aşamada gerekli olanlar aşağıda özetlenmiştir:

Veri Havuzu (Pool): Verileri birbirinden mantıksal olarak ayırmak üzere tasarlanmış, içerisinde imajları barındıran üst seviye bileşenlerdir. Her veri havuzu oluşturulurken veri miktarı ile doğru orantılı olarak belirlenen yerleşim grubu sayısı ile birlikte oluşturulur.

İmajlar (Images): Veri havuzlarının içerisinde yer alan ve blok depolama kullanmak üzere kullanılan bileşenlerdir.

Yerleşim Grubu (Placement Group-PG): Verileri gruplamak üzere OSD ve veri havuzları arasında kullanılan yapı taşlarıdır. OSD başına PG ortalamasının 100-150 civarı olması önerilmektedir. OSD başına PG sayısının 300’ü geçmesi sakıncalı bulunmaktadır.

Kural Grubu (Ruleset): Ceph’in kullandığı CRUSH algoritmasına ait haritanın (CRUSH Map) veriyi özel tanımlar ile hiyerarşik yapıda dağıtmasına izin vermek için kullandığı kurallardır. Varsayılan olarak hiyerarşik yapıda Region/DC/Room/Pod/PDU/Row/Rack/Chassis/Host/OSD olarak tanımlanan sırada örneğin farklı disk tiplerinden farklı veri havuzları oluşturarak (SSD’ler için ayrı, SAS’lar için ayrı, SATA’lar için ayrı) bu kurallar vasıtasıyla ilgili veri havuzlarının ilgili disk gruplarını kullanması sağlanır.

Buna göre herhangi bir istemci bir veri yazma talebinde bulunduğu zaman aşağıdaki resimdeki sıra ile yazılacak alan belirlenir ve replika sayısına göre kopya çıkarılır.

• Öncelikle istemci tarafından yazılacak veri belirlenir ve Ceph üzerinde bulunan bir veri havuzuna yazma talebi yapılır.
• CRUSH algoritması çalıştırılarak istemcinin yazması gereken PG ataması yapılır. Bu esnada herhangi bir metadata sunucusuna veya başka bir lookup tablosuna bakılmaz.
• CRUSH algoritması ayrıca kullanılacak PG’yi bir OSD ile eşler. Böylece istemci veriyi birincil olarak belirlenen PG dolayısıyla OSD üzerine yazar.
• CRUSH tarafından belirlenen birincil OSD’ye yazma işlemi tamamlanınca, verinin kopyası replika sayısına bağlı olarak diğer OSD’lere yazılır. Örneğin replika sayısı 3 ise birincil OSD’ye yazılan veri 2 ayrı OSD’ye daha kopyalanır. Bu OSD’ler varsayılan CRUSH map ayarlarında farklı sunucular üzerinde olacak şekilde ayarlanmıştır. Tüm kopyalar yazıldıktan sonra istemciye yazma işleminin başarılı olduğu bilgisi verilir.

CRUSH Algoritması

CRUSH (Controlled Replication Under Scalable Hashing), Ceph üzerinde verinin nereye yazılıp nereden okunacağını bir hesaplama yaparak belirleyen ve hem istemci hem de sunucularda bulunan, bu sayede veri lokasyonu için ikinci bir işlem gerektirmeyen bir algoritmadır. Daha önce bahsedildiği gibi Ceph bu yaklaşım sayesinde yüksek ölçeklere rahatlıkla çıkabilmektedir.

CRUSH map rolü ve sorumlulukları aşağıdaki gibidir:

• Her hiyerarşik yapı için tanımlanan kurallarla birlikte Ceph’in veriyi nasıl saklayacağını belirler.
• Çok aşamalı olabileceği gibi en az bir düğüm ve yaprak hiyerarşisine sahip olmalıdır.
• Hiyerarşideki her düğüm sepet (bucket) olarak adlandırılır ve her sepetin bir tipi vardır.
• Verileri tutan nesneler disklere verilebilecek ağırlıklara disklere dağıtılır.
• İhtiyaca göre istenilen esneklikte hiyerarşik yapı tanımlanabilir. Tek kısıt en alttaki yaprak ismi verilen düğümler OSD’leri temsil etmelidir. Ayrıca her yaprak düğüm bir sunucuya ya da başka bir tipteki sepete bağlı olmalıdır.

OSD ve PG Nedir ?

OSD Nedir ?

• Ceph Cluster’da her bir disk için bir ceph process’i koşmakta ve disk ile ilgili işlemleri yürütmektedir.
• Bu process’e Object Storage Daemon yani OSD denilmektedir.
• Genelde OSD ile bu process veya Ceph Cluster’ındaki her bir disk kast edilmektedir.

PG Nedir ?

• Placement Group’lar (PGs) Ceph client’ları tarafından görünmez fakat Ceph Cluster’larda önemli bir rol oynarlar.
• Bir Ceph Cluster’ı exabyte seviyesinde kapasiteye ulaştırmak için binlerce OSD eklemek gerekebilir.
• Ceph Client’lar objeleri pool lara kayıt ederler. Pool’lar tüm cluster’ın mantıksal alt kümeleri olarak düşünülebilir.
• Bir pool’daki toplam obje sayısı kolayca milyon ve üzeri sayılara çıkabilir.
• Milyonlarca veya daha fazla sayıda obje içeren bir sistemde hangi objenin nerede olduğunu obje bazlı takip etmek performans konusunda sıkıntılar çıkarır.
• Bu nedenle Ceph objeleri “Placement Group” lara ve Placement Group’ları da OSD’lere atar. Böylece hem verimlilik sağlar hem de dinamik bir şekilde objeleri yeniden dağıtabilir. (re-balancing)
• PG ve OSD ilişkisi aşağıdaki diagramlardan daha net anlaşılabilir.

Ceph’de Placement Group’lar (PGs) hakkında detaylı bilgi için RedHat Ceph Dokümanında ilgili bölümü okuyabilirsiniz.

Dikkat !!!

• Ceph’de PG Sayısı artırma en önemli işlemlerden birisidir !
• Ceph’de PG artırma işlemi yavaş ve önerilen yöntemlerle yapılmazsa çok önemli performans sorunlarına yol açabilir.
• PGP_NUM artırma işlemi sonrası veri PG’ler arası taşınmaya başlar ve bu işlem durdurulamaz, geriye alınamaz ve bu işlemin bitmesi beklenmelidir.
• PG artırma işlemi cluster’ın az yoğun kullanıldığı saatlerde yapılmalıdır.
• İşlem sırasında kullanıcılar yaşanabilecek potansiyel performans etkileri konusunda bilgilendirilmelidir!
• İşlem yapılmadan önce daha yeni dokümanlar da incelenmelidir.

PG Sayısının Önemi

Ceph Cluster’ da Placement Group (PG) sayısı performans ve veri dağıtımı için çok kritik öneme sahiptir. Optimum değerleri bulmak için PG Hesap Makinesi kullanılmalıdır.

RedHat Ceph PG Calc

PG Hesap Makinesinde detaylı olarak da görülebileceği üzere Ceph’ de OSD başına 100 ile 300 arası PG tavsiye edilmektedir.

Ceph’de yeni bir pool oluştururken pool başına düşen PG (Placement Group) sayısını belirtebiliyoruz.

PG Sayısı ne zaman artırılmalı ? Performans ve veri sağlamlığını sağlamak için PG sayısını artırmamız gereken durumlar:

• Zaman içerisinde cluster’ımıza yeni OSD’ler eklediysek, OSD başına düşen PG miktarı 100 ve altına düştüyse
• PG sayısı ilk cluster kurulumunda yanlış belirlendiyse

PG artırma işlemi çok önemli olduğu için yükseltme yapmadan önce dikkatli planlama yapılmalı ve yakın öngürülebilir gelecekteki muhtemel cluster büyümeleri de hesaba katılmalıdır.

Eklenen her bir PG için OSD Node’ları ve Monitor Node’larının kaynak tüketimi (Memory, CPU, Network) artıyor, özellikle recovery işlemi sırasında bu kaynak tüketiminin daha da artacağı belirtiliyor.

PG sayısını minimum’da tutmak:

Kaynak tüketimini düşürüyor.
Verilerin dengesiz dağıtılmasına neden oluyor !

Ceph MGR Nedir ?

Depolama kullanımı, mevcut performans ölçümleri ve sistem yükü dahil olmak üzere çalışma zamanı ölçümlerini ve Ceph kümesinin mevcut durumunu takip etmekten sorumludur.

Ceph MON Nedir ?

MON map, Manager map, OSD map, MDS map ve CRUSH map dahil olmak üzere küme durumunun haritalarını tutar.
Bu haritalar, Ceph arka plan programlarının birbiriyle koordine olması için gerekli olan kritik küme durumudur.

Proxmox VE Ceph Storage Kurulumu

Artık Proxmox VE Ceph Storage kurulumuna başlayabiliriz.

Kurup cluster oluşturduğumuz node’ lara Ceph Install yapmamız gerekiyor bunu ister GUI üzerinden isterseniz de cli üzerinden yapabilirsiniz. Ben kurulum sırasında GUI üzerinden ilerledik ama her adımda cli üzerinden de ilgili komut satırlarını yazacağım.

#pveceph install

Sonrasında kuracağımız sürümü burda tercih ediyoruz ama dikkat edilmesi gereken bir durum var Proxmox VE’ nin sürümü ile Ceph’in sürümün uyuşması gerekiyor. Ben yaptığım testlerde 17.2’nin quincy stabil çalışmadığını gördükten sonra 16.2 pacific versiyonunu kurduk.

Burada dikkat edilmesi gereken bir diğer konu ise community edition kullandığımız için Proxmox VE’nin community’ si üzerinden iki ürünün uyumunu sorgulamamız gerekiyor.

Next diyerek devam ediyoruz ve karşımıza cluster configuration ekranı gelecek burada ilk node’u seçiyoruz ve bunu Ceph Mon olarak seçiyoruz. Burada dikkat edilmesi gereken bir konu cluster network olacak, kurulumun ilerleyen adımlarında onuda cli üzerinden değiştireceğiz.

Burada network takımınız ile istişare ederek bond mimarisinde bir network config’i ile cluster network’ünüzü ayrı bir vlan ile ayırabilirsiniz.

İlk node kurulumumuz tamamlandı sonrasında diğer node’larada ceph install işlemini yapıyoruz. Zatan burada kurulumlarla birlikte her node’un ceph mon‘u gelecektir. Biz daha sonrasında ceph mgr’ leri diğer node’ lara kuracağız.

CLI üzerindende aşağıdaki komutlarla kurulumlarınızı yapabilirsiniz.

#pveceph createmon

#pveceph createmgr

Ceph Install işlemimiz tamamlandı, ceph mon‘lar kuruldu ve ceph mgr‘ler kuruldu.
Burada yapmamız gereken bir diğer şey yazının içinde bahşetmiş olduğumuz cluster_network ve public_network düzeltilmesi olacak.

İlgili resimde ip’ler ilk node’a kurmuş olduğumuz ip ile geliyor biz bunları ilgili ip bloğu olarak değiştireceğiz.

nano etc/pve/ceph.conf

Artık disklerimizi OSD olarak ayarlayabiliriz. Diğer adımlarda yapmış olduğumuz üzere burada da hem GUI üzerinden hemde cli üzerindenişlem yapma imkanımız bulunuyor. Node üzerindeki diskleri tek tek OSD olarak grupluyoruz.

#pveceph osd create /dev/sd[X]

Aşağıdaki resimde görüldüğü gibi 3 node’lu bir Proxmox VE Cluster‘da 6’şar adet diskimizi her node üzerinde OSD olarak ayarladık.

Son olarak 3 node’ da oluşturmuş olduğum OSD‘leri bir pool altında toplamaya.

Create Ceph Pool diyerek karşımıza gelen ekran da pool’ umuza bir isim veriyoruz, replication size’ı “3“, minimum kopya sayısınıda “2” olarak bırakıyoruz.

Burada dikkat edilmesi gereken bir konu ise “PG Autoscale Mode” bunun “0ff” durumda olması gerekiyor neden diyecek olursanız yazımızın ilk bölümlerinde bahsetmiştik “PG” sayısının düşürülmesi yada yükseltilmesi kritik olduğundan dolayı bunu “On” bırakmamamız gerekiyor.

Son olarak gelelim “Number of PGs” ve “Min. Number of PGs” ayarlarına. Burada dikkatli davranmalıyız ve hesap yapmalıyız. Zatan “PG” sayısını ayarlarken mutlaka 2 ve katları olacak şekilde ayarlamalıyız.

Bizim ortamımız için yapılan hesaplamada ortam da 3 node var ve her node da 6 disk var buda 3×6 yaptığımızda 18 OSD ediyor. Replication size’ı “3” olarak düşündüğümüzde her OSD‘ye 128 PG veriyoruz zaten PG sayıları 100 ile 300 aralığında olmalıdır. 128 PG x 6 disk yaptığımızda node başına 768 PG oluyor bunu cluster olarak hesap ettiğimizde 768 PG x 3 node 2304 PG ediyor. Bunuda 3 replication size’a böldüğümüzde sayı 768 PG olarak karşımıza geliyor ama ileriye dönük büyümeyide düşünerek +1 fazlasını veriyorum ve number of PGs sayısını 1024 yapıyorum.

Yani minumum PGs 128 number of PGs ise 1024 olarak ayarlanıyor.

Tüm hesaplarda tamamlanınca bu pool’u storage olarak ekleyeceğiz. Add as Storage tikini işaretliyoruz.

Ceph Cluster’ın status durumunu kontrol etmek için herhangi bir node’a cli üzerinden bağlanıp “ceph status” komutunu çalıştırıyoruz.

Ceph mimarisi tarafında desteklerini esirgemeyen mesai arkadaşlarım Yusuf Güngör ve Mesut Şahin‘e ayrıca teşekkür ederim.

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox VE Ceph Storage Kurulumu appeared first on BURAK AKTAŞ.

Proxmox VE (Virtual Environment) ile bir cluster kurulumunda minimum ve maksimum node sayıları şu şekildedir:

• Minimum Node Sayısı: Proxmox VE ile bir cluster oluşturmak için en az 2 node gereklidir. Ancak, tek bir node ile de çalışabilir ve yönetim işlemlerini gerçekleştirebilirsiniz.
• Maksimum Node Sayısı: Proxmox VE clusterında resmi olarak desteklenen maksimum node sayısı 32’dir. Ancak, bu sayı donanım ve ağ yapılandırmasına bağlı olarak değişebilir ve daha büyük ölçekli kurulumlar için dikkatli planlama ve yapılandırma gerektirir.

Cluster yapılandırmasında her node, merkezi bir yönetim arayüzü üzerinden izlenebilir ve yönetilebilir. Ayrıca, yüksek erişilebilirlik (HA), canlı geçiş (live migration) ve yük dengeleme gibi özelliklerden de yararlanabilirsiniz.

Ben yazımda iki node’ lu bir cluster yapısı anlatıyor olacağım. PVE-01 ve PVE-02’yi birbirine cluster yapacağız.

Node farketmez herhangi bir node’ un en tepesine giderek Datacenter seviyesinde “Create Cluster” diyoruz.
Cluster’ı GUI üzerinden veya cli üzerinden yapabiliriz.

CLI üzerinden yapmak istediğimizde ilgili node’ un cli’ ından “pvecm create clustername” komutunu kullanıyoruz.

Cluster’a bir isim veriyoruz ve create diyip devam ediyoruz.

Resimde gördüğünüz gibi Proxmox VE cluster mimarisine geçiş yaparken corosync servisi ile bu işi yapıyor ve gerekli dataları ilgili conf dosyalarına yazarak restart edip cluster filesystem’i devreye alıyor.

Proxmox Corosync, Proxmox sanallaştırma platformunun bir bileşenidir ve özellikle yüksek erişilebilirlik (HA) kümeleme için kullanılır. Corosync, bir küme içerisindeki düğümler arasında mesajlaşma ve veri senkronizasyonunu sağlamak için kullanılan bir yazılımdır. İşte Proxmox Corosync hakkında bazı önemli noktalar:

• Küme İletişimi: Corosync, kümedeki düğümler arasında iletişimi sağlar. Bu, düğümlerin birbirleriyle senkronize olmasını ve bir düğümün arızalanması durumunda diğer düğümlerin bu durumu algılamasını mümkün kılar.
• Yüksek Erişilebilirlik (HA): Corosync, Proxmox’un yüksek erişilebilirlik özelliklerini destekler. Bu, bir düğüm arızalandığında diğer düğümlerin otomatik olarak hizmet vermeye devam etmesini sağlar. Böylece kesintisiz hizmet sunumu mümkün olur.
• Mesajlaşma ve Seçim Algoritmaları: Corosync, düğümler arasında mesajlaşma ve seçim algoritmaları kullanarak küme yönetimini gerçekleştirir. Bu sayede, hangi düğümün lider olacağı ve hangi düğümlerin hangi görevleri üstleneceği belirlenir.
• Veri Senkronizasyonu: Corosync, düğümler arasında veri senkronizasyonunu sağlar. Bu, verilerin tutarlılığını ve bütünlüğünü koruyarak herhangi bir düğüm arızasında verilerin kaybolmamasını sağlar.
• Proxmox Entegrasyonu: Proxmox sanallaştırma platformu, Corosync’i entegre ederek kullanıcıların sanal makinelerini yüksek erişilebilirlik modunda çalıştırmasına olanak tanır. Bu, özellikle kritik iş yükleri için önemli bir özelliktir.

Özetle, Proxmox Corosync, Proxmox sanallaştırma ortamında yüksek erişilebilirlik sağlamak için kullanılan bir küme mesajlaşma ve senkronizasyon yazılımıdır.

Cluster mimarisi tek node üzerinde oluştu. Artık PVE-01 bir cluster kümesinde biz bu kümeye PVE-2’yi dahil edeceğiz bunun içinde PVE-01 üzerinden Join Information bilgilerini alıyoruz.

Aldığımız bilgileri bu sefer kümeye dahil edeceğimiz PVE-02’nin Join Cluster sekmesine giderek bilgileri yapıştırıp “root” şifremizi giriyoruz.

Oluşturmuş olduğumuz Proxmox VE Cluster’ına ister GUI, isterseniz de cli üzerinden diğer nodeları ekleyebilirsiniz. Ben GUI üzerinden yapmayı tercih ettim ama cli üzerinden yapmak içinde komutlar aşağıdaki gibidir.

• pvecm create clustername –> Cluster oluşturuyoruz.
• pvecm add pve-node-01 –> Bu komutu cluster’a ekleyeceğimiz node’larda çalıştırıyoruz.
• pvecm status –> Bu komut ile cluster’ın durumunu kontrol ediyoruz.

Bu işlemi tüm node’larda sırası ile yaptıktan sonra tüm Proxmox VE node’ larının cluster altında toplandığını görüyoruz.

Cluster’ın status durumunu kontrol etmek için herhangi bir node’a cli üzerinden bağlanıp “pvecm status” komutunu çalıştırıyoruz.

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox VE Cluster Yapılandırması appeared first on BURAK AKTAŞ.

İlk olarak Proxmox VE‘yi kurmak için ilgili link’den iso’muzu download ediyoruz.

https://www.proxmox.com/en/downloads/proxmox-virtual-environment/iso

Proxmox VE iso dosyası kurulum yapılacak sunucuya mount edildikten sonra “Welcome to Proxmox Virtual Environment” ekranında ”Install Proxmox VE” tıklanır.

”End User License Aggrement (EULA)” ekranında ”I agree“ tıklanarak devam edilir.

Proxmox VE dosyalarının kurulumunun yapılacağı disk için ”Target Harddisk” kısmında disk seçilerek ”Next“ tıklanır.

Varsayılan dosya sistemi ext4‘tür. Ext4 veya xfs seçildiğinde Logical Volume Manager (LVM) kullanılır.

İşletim sistemi sürücüsü için yaygın bir uygulama controller arabirimini kullanarak RAID-1 array kullanmaktır. Bu disklerden biri arızalanırsa disk yedekliliği sağlar. Aynı yedeklilik düzeyi, ZFS gibi software-RAID array‘i kullanılarak da elde edilebilir. Fakat tavsiyem Proxmox VE‘nin kurulum yapılacağı OS diskleri fiziksel raid yapılmalıdır.

Proxmox VE kurulumun hemen başında işletim sistemi diski için ZFS tabanlı array seçme seçenekleri sunmaktadır.

ZFS tabanlı seçenekler için ”Options“ tıklanır filesystem’deki seçenekler aşağıdaki gibidir.

Benim test amaçlı kurmuş olduğum sunucular üzerinde raid controller olmadığından dolayı bizde zfs (RAID1) yaparak işletim sistemi Proxmox VE‘yi kuracağız. Ekran görüntüsünde de görüldüğü üzere ilgili diskleri seçiyoruz ve software-RAID yapıyoruz.

”Location and Time Zone Selection” ekranında Country, Time Zone ve Keyboard Layout seçilerek ”Next“ tıklanır.

”Administration Password and E-mail Address” ekranında Password, Confirm ve e-mail kısımları doldurularak ”Next“ tıklanır.

”Management Network Configuration“ ekranında Proxmox VE node’un yönetim arayüzüne erişimin yapılacağı network kartının seçimi için ”Management Interface“ seçildikten sonra Hostname (FQDN), IP Address, Netmask, Gateway ve DNS Server bilgileri girilerek ”Next“ tıklanır.

Bu ekranda yanlızca 1 adet DNS Server IP adresi girilmektedir. 1’den fazla dns tanımını kurulum sonrasında GUI üzerinden veya cli ile /etc/resolv.conf dosyasından ekleyebiliyoruz.

”Summary“ ekranında bir önceki ekranlarda girilen bilgiler kontrol edilerek kurulumun başlaması için ”Install” tıklanır.

”Installation Successful!“ Ekranında Kurulumun tamamlandığı bilgisi ve erişimin nasıl yapılması gerektiği ile ilgili bilgiler görülmektedir ”Reboot” tıklanır.

Reboot işlemide tamamladıktan sonra erişim sağlamak için tarayıcınıza kurulum sırasında verilen IP adresi ile aşağıdaki şekilde erişebilirsiniz.

https://ip_address:8006

“User name“ kısmına “root” ve kurulum esnasında verdiğimiz şifreyi ”Password“ kısmına yazarak ”Login“ tıklandıktan sonra aşağıdaki gibi management arayüzüne erişmiş oluyoruz.

Kurulum görüldüğü üzere çok hızlı ve kolay tamamlandı. Burdan sonra şirket politikanıza ve sistem alt yapınıza uygun olarak yapılandırmaları yapabilirsiniz.

Ben kurulumda basit tek nic bridge mode bir kurulum yaptım, burada network ekipleriniz ile istişare ederek Management Config de çift nic bond mimarisi de yapabilirsiniz.

Kurulum sırasında bizden bir adet dns istedi yapınızda 1 den fazla dns server var ise bunları GUI üzerinden veya CLI yardımı ile nano /etc/resolv.conf dosyası içinden tanımlayabilirsiniz.

Sonrasında nano etc/chrony/chrony.conf config dosyasını düzenleyerek kullanmak istediniz ntp’ lerinizi tanımlayabilirsiniz.

Kurulan node üzerinden firewall özelliğini kapatıp birden fazla node kurulumunda firewall’u merkezi yönetebilirsiniz.

Bir diğer önemli konuda repository’ lerin yönetimi. Repo’lar ortamlarınızı upgrade etmek için önem arz etmektedir. Eğer enterprise kullanım yapacaksanız Proxmox‘ dan abonelik almanız gereklidir. Bu vesile ile hem upgrade’ lerinizi hemde herhangi bir sorunda case yönetiminizi sağlıklı ve güvenilir yapabilirsiniz. Abonelik fiyatlarına Proxmox Subscriptions bu link’ den bakabilirsiniz. Eğer kullanımınızı ücretsiz yapmak istiyorsanız ve oluşacak herhangi bir sorunda case yönetimini kendiniz yapacaksanız community repo’ larını takip edip güncellemeniz gerekmektedir. Bu değişiklikleri de nano /etc/apt/source.list ve nano /etc/apt/sources.list.d/pve-enterprise.list üzerinden yapabilirsiniz.

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox VE 7.3 Kurulumu appeared first on BURAK AKTAŞ.