[{"content":" Problem? Zaman zaman hepimizin karşılaştığı türden bir alarmla karşılaştım: vCenter sunucusunun /storage/archive diski %90 seviyelerindeydi. Normalde bu disk ara sıra dolar ve kendini temizlerdi, bu nedenle biraz kendi haline bırakıp gözlemlemek istedim ancak bu sefer hiç temizlemeye niyeti yoktu ve dolmaya devam ediyordu. Ben de bir yandan bu durumla ilgili Broadcom KB makalelerini incelemeye koyuldum.\nBroadcom’un KB’lerini incelediğimde aşağıdaki önemli noktalar dikkat çekiyordu:\nvCenter’daki birçok dizin yüksek doluluk oranlarına çıkabilecek şekilde tasarlanmıştır. Çoğu durumda, bir bölüm %78-79 seviyesine ulaştığında, uyarıları tetiklemek için gereken %80’i aşabilir ve ardından daha düşük bir yüzdeye geri dönebilir. Benzer şekilde, %93’e ulaştığında, vmware-vpxd hizmetinin kapanmasını tetiklemek için gereken %95’i aşabilir ve ardından daha düşük bir yüzdeye geri dönebilir. Bu durumlar genellikle otomatik temizleme veya sistem davranışının bir parçasıdır. Archive Bölümünün Özelliği\nDiğer bölümlerden farklı olarak, sorun yaşadığımız /storage/archive bölümü tasarım gereği dolu olabileceğinden (evet, %100’e ulaşması da normal kabul ediliyor) vCenter Server’ın herhangi bir işlemini etkilemiyor. Bu birim, mümkün olduğunca çok WAL geçmişi depolar ve arşivleyici hizmeti tarafından en eski WAL segmentleri otomatik olarak kaldırılarak kendiliğinden temizlenir.\nBu birim özelinde vCenter Server 6.7 Update 1b’den itibaren alarmlar durumu oluşmamaktadır. Bu nedenle, yeni sürümlerde arşiv diski %100 dolu olsa bile VAMI’deki özet sekmesinin sağlık durumunda herhangi bir alarm oluşmayacaktır, çünkü bu tasarım gereğidir ve vCenter’ın çalışması üzerinde herhangi bir etkisi yoktur.\nBroadcom makalesinde de bu bölüm özelinde problem çözümünü(!) aşağıdaki gibi adreslemiş:\nFilesystem Mounted on Resolution /dev/mapper/archive_vg-archive /storage/archive “Note: This partition being full is normal and expected in vCenter versions 6.7 and above” “File system /storage/archive is low on storage space” warning in vCenter Server Appliance 6.7/7.x/8.x (318803) Manuel Müdahale Edilebilir mi?\nEvet, Broadcom’un da belirttiği gibi bu bölüm %100 dolup kendini temizleyebiliyor. Ancak, benim vCenter sunucumda bu durum gün aşırı yaşandığından dolayı “false positive” alarmların oluşmasına sebebiyet veriyordu. Zaten kendileri de bazı yapılarda diskin yetersiz geldiği durumlarda diski genişletebileceğinizi belirtiyor.\nBenim sunucumdaki path’i incelediğimde 3 günden fazla arşiv tutamadığını gördüm. Bu da çok kısa bir döngü olmasından dolayı disk genişletme kararı verdim. İSterseniz tek seferlik bir temizleme işlemi de yapabilirsiniz.\nManuel Arşiv Temizleme\nDilerseniz kendiniz manuel olarak da bu dizini temizleyebilirsiniz. Bu, disk genişletme yapmadan önce geçici bir çözüm veya anlık bir rahatlama sağlayabilir.\nSSH ile vCenter Server Appliance’a bağlanıyoruz. shell komutu ile root‘a geçiyoruz. /storage/archive/vpostgres dizinine gidiyoruz. cd /storage/archive/vpostgres Belirli bir günden eski arşivleri listelemek için:find * -mtime +3 komutunu kullanıyoruz. Bu komut bize üç günden eski arşiv dosyalarını listeleyecektir. Listelediğimiz eski arşivleri temizlemek için:find *.* -mtime +3 | xargs rm komutunu kullanıyoruz. Temizleme sonrası df -h komutu ile kontrol ettiğinde archive dizininde bir rahatlama göreceksiniz. Diskini Genişletme Adımları\nBen, arşivlenebilen günün çok az olması nedeniyle disk genişletme işlemi yaptım. Bu işlem de sırasıyla şu şekildedir:\nÖn Hazırlıklar ve Dikkat Edilmesi Gerekenler:\nvCenter Server’ın yedeğini alın: Kenarda bir yedeğinizin olması iyi olur. Alalım dursun kenarda 🙂 Mevcut Snapshot’ları Silin: Disk genişletmeden önce vCenter VM üzerinde herhangi bir snapshot varsa silmemiz öneriliyor. 1. Doğru Diski Tespit Etme:\nvCenter üzerinde 17 tane Virtual Disk bulunuyor. Öncelikle genişleteceğimiz /storage/archive diskinin SCSI bağlantısını tespit etmemiz ve ona uygun şekilde artırım yapmamız gerekiyor.\nlsblk -o NAME,HCTL,MOUNTPOINT,SIZE komutu ile vCenter sunucumuzun disklerini ve mount pointlerini listeleyebiliriz.\nroot@vcsatst [ ~ ]# lsblk -o NAME,HCTL,MOUNTPOINT,SIZE NAME HCTL MOUNTPOINT SIZE sda 2:0:0:0 48.6G ├─sda1 4M ├─sda2 /boot/efi 10M ├─sda3 /boot 512M └─sda4 48G └─vg_root_0-lv_root_0 / 48G sdb 2:0:1:0 7.2G sdc 2:0:2:0 25G └─swap_vg-swap1 [SWAP] 25G sdd 2:0:3:0 50G └─core_vg-core /storage/core 50G sde 2:0:4:0 10G └─log_vg-log /storage/log 10G sdf 2:0:5:0 10G └─db_vg-db /storage/db 10G sdg 2:0:6:0 15G └─dblog_vg-dblog /storage/dblog 15G sdh 2:0:8:0 1.4T └─seat_vg-seat /storage/seat 1.4T sdi 2:0:9:0 1G └─netdump_vg-netdump /storage/netdump 1016M sdj 2:0:10:0 10G └─autodeploy_vg-autodeploy /storage/autodeploy 10G sdk 2:0:11:0 10G └─imagebuilder_vg-imagebuilder /storage/imagebuilder 10G sdl 2:0:12:0 100G └─updatemgr_vg-updatemgr /storage/updatemgr 100G sdm 2:0:13:0 100G └─archive_vg-archive /storage/archive 100G sdn 2:0:14:0 1.4T └─vtsdb_vg-vtsdb /storage/vtsdb 1.4T sdo 2:0:15:0 15G └─vtsdblog_vg-vtsdblog /storage/vtsdblog 15G sdp 3:0:0:0 100G └─lifecycle_vg-lifecycle /storage/lifecycle 100G sr0 0:0:0:0 1024M sdq 3:0:1:0 1000G └─vg_lvm_snapshot-lv_lvm_snapshot /storage/lvm_snapshot 1000G Yukarıdaki çıktıda görüldüğü üzere/storage/archive diskimiz sdm olarak listelenmiş ve SCSI controller 0, Virtual Device Node SCSI(0:13) üzerinde yer alıyor.\n2. vCenter Üzerinden Sanal Diski Büyütme:\nvCenter arayüzü üzerinden vCenter VM’ine sağ tıklayıp “Edit Settings” seçeneğini seçerek Hard disk 13 olarak görünen ve /storage/archive‘a karşılık gelen diskin boyutunu artırıyoruz.\nvCenter sunucusuna SSH ile bağlanıyoruz ve shell komutu ile root’a geçiyoruz. Burada extend işlemini kolaylaştırmak için Broadcom’un yerleştirdiği bir script var. Onu çalıştırmamız yeterli olacak. /usr/lib/applmgmt/support/scripts/autogrow.sh komutu ile scripti çalışıtıyoruz.\nScript bizim için extend işlemini gerçekleştirecektir. Scriptin çalışması tamamlandıktan sonra df -h komutu ile /storage/archive dizinine karşılık gelen sdm diskini kontrol edebilirsiniz.\nBöylelikle çok da sorun olmayan bir sorunun üstesinden gelmiş oluyoruz. Okuduğunuz için teşekkürler.\nReferanslar\nvCenter Server Appliance disk space is full\n“File system /storage/archive is low on storage space” warning in vCenter Server Appliance 6.7/7.x/8.x\nIncreasing the disk space for the vCenter Server Appliance in vSphere 6.5, 6.7, 7.0 and 8.0\nHow To Remove Old Archive Files in VMware vCenter Server Appliance\n","permalink":"https://kemalbiyikli.com/vcenter-archive-is-full/","summary":"\u003chr\u003e\n\u003ch3 id=\"problem\"\u003eProblem?\u003c/h3\u003e\n\u003cp\u003eZaman zaman hepimizin karşılaştığı türden bir alarmla karşılaştım: vCenter sunucusunun \u003ccode\u003e/storage/archive\u003c/code\u003e diski %90 seviyelerindeydi. Normalde bu disk ara sıra dolar ve kendini temizlerdi, bu nedenle biraz kendi haline bırakıp gözlemlemek istedim ancak bu sefer hiç temizlemeye niyeti yoktu ve dolmaya devam ediyordu. Ben de bir yandan bu durumla ilgili Broadcom KB makalelerini incelemeye koyuldum.\u003c/p\u003e\n\u003cp\u003eBroadcom’un KB’lerini incelediğimde aşağıdaki önemli noktalar dikkat çekiyordu:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003evCenter’daki birçok dizin yüksek doluluk oranlarına çıkabilecek şekilde tasarlanmıştır. Çoğu durumda, bir bölüm %78-79 seviyesine ulaştığında, uyarıları tetiklemek için gereken %80’i aşabilir ve ardından daha düşük bir yüzdeye geri dönebilir.\u003c/li\u003e\n\u003cli\u003eBenzer şekilde, %93’e ulaştığında, \u003ccode\u003evmware-vpxd\u003c/code\u003e hizmetinin kapanmasını tetiklemek için gereken %95’i aşabilir ve ardından daha düşük bir yüzdeye geri dönebilir. Bu durumlar genellikle otomatik temizleme veya sistem davranışının bir parçasıdır.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eArchive Bölümünün Özelliği\u003c/strong\u003e\u003c/p\u003e","title":"vCenter: Archive is full"},{"content":"Geçtiğimiz hafta sanallaştırma altyapımıza yeni bir sunucu ekledim. Her şey yolunda gidiyor derken MSA2060 üzerindeki bir Volume’ü sunucuya mount edemedim. Neden oldu, nasıl çözeriz derken aşağıdaki gibi bir süreç gelişti.\nİş Senaryosu Hali hazırda MSA2060 storage’ımızda aktif olarak kullanılan 2 adet LUN var. Yeni bir ESXi host vCenter ortamına eklendi. Bu hosta storage iSCSI ile bağlandı. LUN’lardan biri datastore olarak başarıyla mount edildi. Ancak bir LUN datastore listesinde yok ve mount edilemiyor. “Storage Devices” altında LUN görünüyor, ama “Not Consumed” durumu var. Tanılama Aşaması ÖProblemi tespit etmek için aşağıdaki kontroller yapıldı.\nTüm iSCSI initiator’leri ve bağlantılarını kontrol edildi. Hostumuzun VMKernel ve iSCSI konfigürasyonları kontrol edildi. Storage üzerinde Volume Groups ve Host Groups bölümlerini ve mappingleri kontrol ediyoruz. Tüm LUN’ların hostlara aynı id’ler ile bağlı olup olmadığı kontrol edildi. Öncelikle tüm fiziksel bağlantı ve konfigürasyonların doğruluğundan emin olduktan sonra sorunu storage üzerinde aradım. Çünkü hostlarıma bağlı olan diğer storage’larla hiçbir sorun yaşamazken bu storage’da LUN’lardan birini bağlarken diğerini bağlayamamış olmam beni storage tarafını kontrol etmeye itti.\nHPE ile yapılandırmayı kontrol ettik. Onlar’da herhangi bir yapılandırma hatası göremedi ve ticket’ı L2 mühendise eskale ettiler. Logları ve problemi inceleyen mühendis çözüm için Controller’ları sıra ile restart etmemi önerdi. Ancak bu yöntemi canlı sistemleri etkileme riskinden dolayı son seçenek olarak kenara koydum.\nBu aşamada internetten durumu araştırınca bu konuyla ilgili bazı KB ve forum yorumlarına denk geldim. Nitekim çözümü de storage üzerinde değil de esxi üzerinde buldum. Şimdi kısaca bu durumun neden gerçekleştiğine bakalım:\nESXi hostlar, üzerinde başka bir host tarafından formatlanmış bir VMFS volume varsa, bunu otomatik olarak mount etmez.(Aslında bazı durumlarda edilebiliyor ama çok değişkenli bir fonksiyon gibi bir durum var. Her ihtimali şu an yazmak kafa karıştırıcı olacaktır, refernas linkini veriyorum.) Bunun sebebi veri kaybı riskidir. ESXi bu LUN’u “foreign VMFS” olarak algılar ve sizin manuel olarak mount etmenizi ister. Bu noktada New Datastore diye eklediğinizde o volume’ü görürsünüz ve devam etmek istediğinizde de bak dostum böyle bir bölüm var ben bunu koruyarak eski isim ve id’si ile ekleyeyim mi dye sorar.\nBuraya kadar herşey normal, ancak ben bu volume’ü yeni bir datastore ekler gibi eklemek istediğimde de göremiyordum. Bu durumun ESXi, yeni eklenen bir LUN’da mevcut VMFS imzası görürse, veri kaybı riskini önlemek için tasarım gereği volume’u snapshot olarak algılamasından kaynaklanıyor.\nTroubleshooting LUNs detected as snapshot LUNs in vSphere\nBu durumda force mount ile problemi çözebiliriz ancak bunun da beraberinde getireceği bazı problemler var. Kısaca özetlemek gerekirse:\nForce mount: Datastore’u herhangi bir kesinti yaşatmadan mount eder, UUID değişmediği için ileride GUI üzerinden genişletme yapamazsınız, ve yeni hostlarda mount edilme problemi tekrar yaşanabilir.\nResignature: Yeni UUID ile datastore yeni bir imza kazanır. Böylece koruma mekanizması devre dışı kalır, ama yeniden mount edilirken GUI kısıtlamaları azalır. Ancak bu işlemi yapabilmek için datastore’u maintenance modeuna almak gerekiyor.\nÇözüm Adımları Exsi’a SSH ile bağlanarak aşağıdaki komutu çalıştırıyoruz. Bu komut, sistem tarafından algılanmış ama mount edilmemiş VMFS volume’ları listeler.\nesxcli storage vmfs snapshot list Örnek çıktı:\n66759913-1a8be7cc-960f-0800691800c8 Volume Name: MSA2022_Pool01 VMFS UUID: 66759913-1a8be7cc-960f-0800691800c8 Can mount: true Reason for un-mountability: Can resignature: false Reason for non-resignaturability: the volume is being actively used Unresolved Extent Count: 1 Volume Mount Durumu\nCan mount: true ise mount edilebilir. Can resignature: false ve “actively used” ibaresi varsa, bu volume başka host tarafından zaten kullanılıyor. Bu durumda resignature işlemi yapmak isteiğimizde hata verecektir. Zorla yapmaya çalışırsak eğer de veri kaybı yaşayacağız. Bu nedenle datastore’u resignature yapmadan herhangi bir değişiklik yapmadan mount edeceğiz. esxcli storage vmfs snapshot mount -u 66759913-1a8be7cc-960f-0800691800c8 Sonuç Problemimi şu an için force mount ile gidermek iş sürekliliği açısından en efektif çözümdü ancak ileride datastore extend gibi işlemleri gui üzerinden yapabilmek ya da yeni hostlar bağladığımda benzer problemleri yaşamamak adına resignature ile datastore’u tekrar bağlamak en sağlıklı yol olacaktır.\n","permalink":"https://kemalbiyikli.com/vmware-esxi-cannot-mount-existing-iscsi-datastore/","summary":"\u003cp\u003eGeçtiğimiz hafta sanallaştırma altyapımıza yeni bir sunucu ekledim. Her şey yolunda gidiyor derken MSA2060 üzerindeki bir Volume’ü sunucuya mount edemedim. Neden oldu, nasıl çözeriz derken aşağıdaki gibi bir süreç gelişti.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"iş-senaryosu\"\u003eİş Senaryosu\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eHali hazırda MSA2060 storage’ımızda aktif olarak kullanılan 2 adet LUN var.\u003c/li\u003e\n\u003cli\u003eYeni bir ESXi host vCenter ortamına eklendi.\u003c/li\u003e\n\u003cli\u003eBu hosta storage iSCSI ile bağlandı.\u003c/li\u003e\n\u003cli\u003eLUN’lardan biri datastore olarak başarıyla mount edildi.\u003c/li\u003e\n\u003cli\u003eAncak bir LUN datastore listesinde yok ve mount edilemiyor.\u003c/li\u003e\n\u003cli\u003e“Storage Devices” altında LUN görünüyor, ama \u003cstrong\u003e“Not Consumed”\u003c/strong\u003e durumu var.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"tanılama-aşaması\"\u003eTanılama Aşaması\u003c/h2\u003e\n\u003cp\u003eÖProblemi tespit etmek için aşağıdaki kontroller yapıldı.\u003c/p\u003e","title":"VMware ESXi – Cannot Mount Existing iSCSI Datastore"},{"content":"Giriş Guacamole, istemci gerektirmeden tarayıcı üzerinden uzak masaüstü bağlantıları yapmanıza olanak tanıyan, açık kaynaklı bir remote desktop gateway çözümüdür. RDP, VNC ve SSH gibi protokolleri destekleyerek çok yönlü kullanım imkanı sunar. Guacamole doğrudan bir sunucuya kurulabilir, ancak bağımlılıklar, güncellemeler, taşınabilirlik açısından Docker ile kurulum yapmak daha pratik ve avantajlıdır. Bu yazımda, Guacamole’un Docker üzerinde nasıl kurulacağını ve yapılandırılacağını adım adım aktarmaya çalışacağım.\n1. Docker Kurulumu Yapıyoruz Docker ve Docker Compose’un kurulumunu aşağıdaki komutlarla gerçekleştiriyoruz.\nsudo apt update sudo apt install -y docker.io docker-compose Kurulum tamamlandıktan sonra, Docker’ın çalışıp çalışmadığını kontrol ediyoruz. Aşağıdakine benzer bir çıktı görmemiz gerekiyor.\nroot@guacamole:~# docker --version Docker version 26.1.3, build 26.1.3-0ubuntu1~24.04.1 root@guacamole:~# docker-compose --version docker-compose version 1.29.2, build unknown 2. Guacamole ve PostgreSQL için Docker Compose Dosyası Oluşturuyoruz Guacamole’un çalışması için 3 ana bileşene ihtiyacımız var:\nguacd Guacamole Daemon servisi postgres Kullanıcı ve Bağlantılar için kullanacağımız veritabanı guacamole Uygulamanın web arayüzü Bu üç bileşenin docker üzerinde kurulumu için öncelikle terminalde şu komutları çalıştırarak bir klasör ve konfigürasyon dosyası oluşturuyoruz.\nroot@guacamole:~# mkdir guacamole-docker root@guacamole:~# cd guacamole-docker root@guacamole:~/guacamole-docker# nano docker-compose.yml Docker Compose içeriğinde neler var? Açılan docker-compose.yml dosyasına servislerin kurulumu için gerekli olan içeriği ekliyoruz. Dosyanın içeriği ile ilgili tanımlar şu şekilde.\nguacd: Guacamole’un temel servisi. postgres: PostgreSQL veritabanı servisi. guacamole: Web arayüzünü sağlayan servis. volumes: PostgreSQL’in verilerini kalıcı hale getirmek için kullanılıyor. version: \u0026#39;3\u0026#39; services: guacd: image: guacamole/guacd container_name: guacd restart: always postgres: image: postgres:13 container_name: guac-postgres restart: always environment: POSTGRES_DB: guacamole_db POSTGRES_USER: guacuser POSTGRES_PASSWORD: guacpass volumes: - guac-postgres-data:/var/lib/postgresql/data guacamole: image: guacamole/guacamole container_name: guacamole restart: always depends_on: - guacd - postgres ports: - \u0026#34;8080:8080\u0026#34; environment: GUACD_HOSTNAME: guacd POSTGRES_HOSTNAME: postgres POSTGRES_DATABASE: guacamole_db POSTGRES_USER: guacuser POSTGRES_PASSWORD: guacpass volumes: guac-postgres-data: 3. Docker Servislerini Çalıştırıyoruz Hazırladığımız docker-compose.yml dosyası ile aşağıdaki komutu kullanarak konteynerleri başlatıyoruz.\ndocker-compose up -d Çalışan konteynerleri kontrol etmek için docker ps komutunu kullanıyoruz.\nroot@guacamole:~/guacamole-docker# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3320aed26c8c guacamole/guacamole \u0026quot;/opt/guacamole/bin/…\u0026quot; 23 hours ago Up 3 minutes 0.0.0.0:8080-\u0026gt;8080/tcp, :::8080-\u0026gt;8080/tcp guacamole 9599dface8ac guacamole/guacd \u0026quot;/bin/sh -c '/opt/gu…\u0026quot; 23 hours ago Up 3 minutes (health: starting) 4822/tcp guacd c90d178d512d postgres:13 \u0026quot;docker-entrypoint.s…\u0026quot; 23 hours ago Up 3 minutes 5432/tcp guac-postgres 4. PostgreSQL için Veritabanını Yapılandırıyoruz Guacamole bağlantı yönetimi, kullanıcı yönetimi gibi işlemleri veri tabanı üzerinden yapmaktadır. Veri tabanında bu verileri barındıracağımız tablolar için PostgreSQL içine bir şema yüklememiz gerekiyor. Şemayı yüklemek için öncelikle bir klasör oluşturuyoruz ve gerekli şemaları klasörün altına indiriyoruz.\nroot@guacamole:~# mkdir init-sql root@guacamole:~# cd init-sql root@guacamole:~/init-sql# wget https://raw.githubusercontent.com/apache/guacamole-client/master/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-postgresql/schema/001-create-schema.sql root@guacamole:~/init-sql# wget https://raw.githubusercontent.com/apache/guacamole-client/master/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-postgresql/schema/002-create-admin-user.sql root@guacamole:~/init-sql# cd .. Veritabanı Şemalarını Yüklüyoruz Şema yükleme işlemini yapmadan önce indirdiğimiz şema dosyalarını taşımamız gerekiyor. Şu anda dosyalarınız host makinenizde /init-sql/ dizini altında bulunuyor. Bu dosyaları Host makinenizdeki /init-sql/ klasörünü PostgreSQL konteynerinizin /init-sql/ dizinine kopyalamak için şu komutu çalıştırıyoruz.\ndocker cp init-sql/ guac-postgres:/init-sql/ Şimdi PostgreSQL konteynerine giriş yapıyoruz.\ndocker exec -it guac-postgres bash Konteyner içinde init-sql klasörünün geldiğini doğrulamak için ls komutu ile klasörün içeriğini kontrol ediyoruz.\nls /init-sql/ Eğer 001-create-schema.sql ve 002-create-admin-user.sql dosyalarını görüyorsak kopyalama işlemi başarılı olmuş demektir.\nŞimdi şema dosyalarını yüklemek için PostgreSQL’e giriş yapıyoruz.\npsql -U guacuser -d guacamole_db PostgreSQL’e giriş yaptıktan sonra sırasıyla şu komutları çalıştırarak şema dosyalarını içe aktarıyoruz.\n\\i /init-sql/001-create-schema.sql; \\i /init-sql/002-create-admin-user.sql; CREATE TABLE, INSERT, gibi mesajlar gördüğümüzde işlem başarılı olmuş demektir. exit diyerek PostgreSQL’den çıkış yapıyoruz ve docker-compose.yml olduğu dizine geri gidiyoruz.\nEğer docker-compose.yml dosyanızın olduğu dizinde değilseniz, hatayla karşılaşırsınız. Önce doğru dizine gidin:\ncd /guacamole-docker Sonrasında konteynerleri tekrar başlatıyoruz.\ndocker-compose up -d Artık Guacamole’ tarayıcımızdan erişebiliriz. (localhost yerine sunucumuzun ip adresini yazıyoruz.)\nAdres: http://localhost:8080/guacamole\nKullanıcı: guacadmin\nParola: guacadmin\nUygulamaya giriş yaptıktan sonra sağ üstteki menüden settings altına gelerek kullanıcı, grup ve bağlantılar gibi seçenekleri yapılandırıyoruz.\nÖrnek olarak connection tabına gelerek bir sunucu ekliyorum.\nSunucu için bir isim ve kullanacağımız ve yapacağımız bağlantı şeklini belirliyoruz. Sunucumuzun ip adresi ve bağlantıyı gerçekleştireceğimiz portu belirliyoruz. Sunucuya login olmak için gerekli olan kullanıcı bilgilerini yazıyoruz. Bağlantıyı oluşturduktan sonra sağ üstteki menüden Home‘a gidiyoruz ve bağlantımızı seçerek çift tıklayıp sunucuya bağlantı işlemini gerçekleştiriyoruz.\nSonuç Guacamole RDP SSH ve VNC gibi ihtiyaç duyacağımız birçok protokolü desteklemektedir. Herhangi bir istemciye ihtiyaç duymadan tarayıcı üzerinden çalıştığı için esnek bir kullanım alanına sahiptir. LDAP, RADIUS, OpenID ve CAS gibi kimlik doğrulama mekanizmalarıyla birlikte grup bazlı yönetimi de destekler. Bu sayede yönetimsel kolaylıkla birlikte ekstra güvenlik katmanı sağlar. Dosya transferi kopyala-yapıştır gibi özellikleri de barındırmaktadır. Kullanıcıların gerçekleştirdiği oturumların video kaydını almanıza imkan tanır. Bir sonraki yazımda oturumların video kaydının harici bir nfs sunucu üzerine nasıl yapıldığını ele alacağım. ","permalink":"https://kemalbiyikli.com/apache-guacamole-kurulumu/","summary":"\u003ch3 id=\"giriş\"\u003e\u003cstrong\u003eGiriş\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eGuacamole\u003c/strong\u003e, istemci gerektirmeden tarayıcı üzerinden uzak masaüstü bağlantıları yapmanıza olanak tanıyan, \u003cstrong\u003eaçık kaynaklı\u003c/strong\u003e bir \u003cstrong\u003eremote desktop gateway\u003c/strong\u003e çözümüdür. \u003cstrong\u003eRDP, VNC ve SSH\u003c/strong\u003e gibi protokolleri destekleyerek çok yönlü kullanım imkanı sunar. Guacamole doğrudan bir sunucuya kurulabilir, ancak bağımlılıklar, güncellemeler, taşınabilirlik açısından Docker ile kurulum yapmak daha pratik ve avantajlıdır. Bu yazımda, Guacamole’un Docker üzerinde nasıl kurulacağını ve yapılandırılacağını adım adım aktarmaya çalışacağım.\u003c/p\u003e\n\u003ch3 id=\"1-docker-kurulumu-yapıyoruz\"\u003e\u003cstrong\u003e1. Docker Kurulumu Yapıyoruz\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eDocker ve Docker Compose’un kurulumunu aşağıdaki komutlarla gerçekleştiriyoruz.\u003c/p\u003e","title":"Apache Guacamole Kurulumu"},{"content":"Redis Nedir? Redis, verileri RAM üzerinde tutarak yüksek hızda okuma ve yazma işlemleri gerçekleştiren bir anahtar-değer (key-value) veri deposudur. Genellikle bir önbellek veya mesaj kuyruğu olarak kullanılır. Geleneksel veritabanlarına kıyasla çok daha hızlı çalıştığı için, performans gerektiren birçok uygulamada tercih edilmektedir.\nRedis’in Kullanım Alanları Önbellekleme (caching): Web uygulamalarında sık kullanılan verilerin hızlı erişilebilir olmasını sağlar. Gerçek zamanlı analiz: Örneğin, leaderboard veya sayfa görüntüleme sayaçları gibi işlemlerde kullanılır. Mesaj kuyruğu: Verileri geçici olarak saklayarak dağıtık sistemlerde mesajlaşma altyapısı sağlar. Oturum yönetimi: Kullanıcı oturumlarını verimli bir şekilde saklayarak performansı artırır. Hangi İşletim Sistemlerinde Çalışır? Redis, en stabil ve performanslı şekilde Linux ortamında çalışmaktadır. Ancak farklı platformlarda da belirli yöntemlerle kullanılabilir:\nLinux: Resmi olarak desteklenir ve production ortamları için önerilen işletim sistemidir. macOS: Geliştirme ve test süreçlerinde kullanılabilir ancak production ortamları için önerilmez. Windows: Resmi bir Redis desteği bulunmamaktadır. Ancak WSL2 veya üçüncü taraf çözümlerle çalıştırmak mümkündür. Üretim ortamları için daima Linux tercih edilmelidir. Genellikle Ubuntu, Debian veya CentOS/Rocky Linux gibi dağıtımlar tercih edilmektedir.\nRedis Cluster Nedir, Nasıl Kurulur? Redis Cluster, yüksek erişilebilirlik ve ölçeklenebilirlik sağlamak amacıyla geliştirilmiş bir yapılandırmadır. Verileri shard’lara bölerek birden fazla sunucuya dağıtır. Bu sayede:\nPerformans artırılır, çünkü yük birden fazla node’a dağıtılır. Tek bir sunucu devre dışı kalsa bile sistem çalışmaya devam eder. Otomatik failover mekanizması sayesinde veri bütünlüğü korunur. 1. Redis Cluster Tasarımı Redis Cluster’ın sağlıklı çalışabilmesi için minimum 6 node’lu bir yapı önerilmektedir:\n3 Master, 3 Replica olmak üzere toplamda 6 node kullanılır. Master node’lar veriyi saklarken, Replica node’lar yedekleme ve failover işlemlerini üstlenir. Bir Master node devre dışı kaldığında, ilgili Replica otomatik olarak Master rolünü devralır. Veriler, sharding yöntemi ile tüm node’lar arasında dengeli bir şekilde dağıtılır. Bu yapılandırma, Redis’in yüksek erişilebilirlik ve ölçeklenebilirlik sunmasını sağlar.\nKurulum Adımları (Ubuntu Server) Örnek olarak 6 Redis Node’u kuruyoruz. Her bir sunucu için benzersiz ip adresleri ve hostname’ler veriyoruz. Şimdi bunları bir cluster’a çevireceğiz.\nSunucu 1: redis01 \u0026gt; 10.10.0.101 \u0026gt; Master 1\nSunucu 2: redis02 \u0026gt; 10.10.0.102 \u0026gt; Master 2\nSunucu 3: redis03 \u0026gt; 10.10.0.103 \u0026gt; Master 3\nSunucu 4: redis04 \u0026gt; 10.10.0.104 \u0026gt; Replica 1\nSunucu 5: redis05 \u0026gt; 10.10.0.105 \u0026gt; Replica 2\nSunucu 6: redis06 \u0026gt; 10.10.0.106 \u0026gt; Replica 3\n1. Redis’in Yüklenmesi Tüm sunucularda Redis kurulumunu gerçekleştirelim:\nsudo apt update -y sudo apt install redis -y Yükleme tamamlandıktan sonra redis servisini kontrol ediyoruz.\nsystemctl status redis 2. Redis Konfigürasyon Dosyası Redis’i tüm sunuculara yükledikten sonra Cluster kurabilmek için tüm sunucularda konfigürasyon dosyasını da düzenlememiz gerekiyor. Aşağıdaki komut ile redisin varsayılan konfigürasyon dosyasına ulaşabilirsiniz.\nnano /etc/redis/redis.conf Redis Yapılandırma Ayarları Redis’in verimli ve güvenilir çalışabilmesi için bazı temel yapılandırma ayarlarının yapılması gerekmektedir. Bu ayarların her biri, Redis’in dayanıklılığını, performansını ve ölçeklenebilirliğini artırmak için kritik öneme sahiptir.\n1. Veri Kaybını Önlemek İçin: appendonly yes Redis, RAM tabanlı çalıştığı için ani bir sunucu çökmesi durumunda tüm verilerin kaybolma riski vardır. Bu durumu önlemek için kalıcı veri saklama (persistence) mekanizmaları kullanılmalıdır. Redis’te iki farklı yöntem bulunmaktadır:\nRDB (Redis Database Snapshot): Belirli aralıklarla tüm veritabanının anlık görüntüsünü (snapshot) alır ve diske yazar. AOF (Append-Only File): Yapılan tüm işlemleri log dosyasına sürekli olarak kaydeder. Önerilen Ayar:appendonly yes\nBu ayar etkinleştirildiğinde Redis, her değişikliği disk üzerinde loglayarak ani çökme durumlarında veri kaybını en aza indirir.\n2. Timeout Ayarları: cluster-node-timeout 5000 Redis Cluster yapısında, düğümler (nodes) arasındaki iletişim kritik bir konudur. cluster-node-timeout parametresi, bir düğümün diğer düğümlerle iletişim kuramadığında ne kadar süre içinde başarısız (failed) olarak işaretleneceğini belirler.\nDüşük bir değer (örneğin 1000 ms) kullanılırsa: Küçük ağ gecikmeleri bile düğümlerin başarısız olarak algılanmasına neden olabilir. Bu durum gereksiz failover işlemlerine yol açarak cluster’ın istikrarsız hale gelmesine sebep olabilir. Çok yüksek bir değer kullanılırsa: Gerçekten çöken bir düğümün fark edilmesi gecikeceği için failover süreci uzar ve hizmet kesintileri yaşanabilir. Önerilen Ayar:cluster-node-timeout 5000\nGenellikle 3-5 saniye arası ideal bir değerdir. Eğer ağ altyapınızda gecikmeler yaşanıyorsa, değeri biraz daha yükseltebilirsiniz.\n3. Bellek Yönetimi: maxmemory ve maxmemory-policy Redis, tüm verileri RAM üzerinde tuttuğu için bellek yönetimi büyük önem taşır. Eğer bellek sınırı belirlenmezse, iki önemli risk ortaya çıkabilir:\nSistem belleği tamamen dolar ve Redis süreci çöker. Bu durumda Redis, sistem tarafından sonlandırılabilir. Yeni veri eklenemez, uygulamalar hata verebilir. Bu da performans problemlerine ve beklenmeyen kesintilere yol açabilir. Bu riskleri önlemek için aşağıdaki iki temel ayarın yapılandırılması gerekmektedir:\na) maxmemory: Redis’in Kullanabileceği Maksimum Bellek Redis’e ne kadar bellek kullanabileceğini belirtmek için maxmemory ayarı kullanılır. Örneğin, Redis’in 2 GB bellek kullanmasını istiyorsak: maxmemory 2gb\nb) maxmemory-policy: Bellek Dolduğunda Uygulanacak Strateji Bellek sınırına ulaşıldığında hangi verilerin silineceğini belirlemek için maxmemory-policy ayarı kullanılır. Yaygın olarak kullanılan ve önerilen politika şudur: allkeys-lru\nBu ayar etkinleştirildiğinde, en az kullanılan eski veriler (LRU – Least Recently Used) bellekten temizlenerek yeni veriler için yer açılır.\n4. Diğer Önemli Yapılandırmalar Bazı ek ayarlar, Redis’in doğru şekilde çalışmasını sağlamak için gereklidir:\ncluster-config-file nodes.conf → Cluster yapılandırma dosyasını tanımlar\nRedis, cluster’daki düğümleri ve bağlantı durumlarını bu dosyada saklar.\nbind 0.0.0.0 → Tüm IP’lerden erişime izin verir\nVarsayılan olarak Redis, sadece localhost üzerinden erişime açıktır. Eğer Redis’e dış ağdan bağlantı sağlanacaksa bu ayarın değiştirilmesi gerekir.\ncluster-enabled yes → Cluster modunu aktif hale getirir\nRedis’in dağıtık mimaride çalışabilmesi için bu ayarın etkinleştirilmesi gerekir.\n5. Konfigürasyon Dosyasının Düzenlenmesi Konfigürasyon dosyasını açıp yukarıda paylaştığım konfigürasyonları eklemek istediğinizde bu neymiş be! diyebilirsiniz. Burada redisle ilgili birçok bilgiyi içeren bilgilerle birlikte kullanmayacağımız birçok ayar da bulunuyor. Bu nedenle yeni ve sade bir konfigürasyon dosyası oluşturmak daha kolay olacaktır. Aşağıdaki komut ile mevcut konfigürasyon dosyasının adını değiştirerek aynı klasör altında redis.conf.backup olarak tutuyoruz.\nmv /etc/redis/redis.conf /etc/redis/redis.conf.backup Eski konfigürasyon dosyasını yedekledikten sonra Aşağıdaki komut ile yeni dosyayı oluşturup aşağıdaki konfigürasyonu içine yazarak kaydediyoruz.\nnano /etc/redis/redis.conf Örnek Konfigürasyon Dosyası # Redis Cluster Konfigurasyonu # Temel Ayarlar port 6379 bind 0.0.0.0 protected-mode no # Cluster Ayarları cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 cluster-require-full-coverage no # Bellek Yönetimi maxmemory 2gb maxmemory-policy allkeys-lru # Disk Kalıcılığı appendonly yes appendfsync everysec dbfilename dump.rdb dir /var/lib/redis/ Dosyamızı tüm sunucularda oluşturup içeriği kaydettikten sonra redis servisini restart ediyoruz.\nsystemctl restart redis 3. Cluster Kurulumu Master ve Replica’ları belirleyerek Cluster’ı oluşturuyoruz:\nredis-cli --cluster create 10.10.0.101:6379 10.10.0.102:6379 10.10.0.103:6379 \\ 10.10.0.104:6379 10.10.0.105:6379 10.10.0.106:6379 --cluster-replicas 1 Komutu çalıştırdıktan sonra aşağıdaki gibi bir çıktı elde ettiğimizde cluster kurulumu tamamlanmıştır\nBu komut: İlk 3 Node’u Master yapar, sonraki 3 Node’u onların Replica’sı olarak ayarlar.\nroot@redis01:~# redis-cli --cluster create 10.10.0.101:6379 10.10.0.102:6379 10.10.0.103:6379 10.10.0.104:6379 10.10.0.105:6379 10.10.0.106:6379 --cluster-replicas 1 \u0026gt;\u0026gt;\u0026gt; Performing hash slots allocation on 6 nodes... Master[0] -\u0026gt; Slots 0 - 5460 Master[1] -\u0026gt; Slots 5461 - 10922 Master[2] -\u0026gt; Slots 10923 - 16383 Adding replica 10.10.0.105:6379 to 10.10.0.101:6379 Adding replica 10.10.0.106:6379 to 10.10.0.102:6379 Adding replica 10.10.0.104:6379 to 10.10.0.103:6379 M: d8710299ca28d14163ea3ecb0427441245a77019 10.10.0.101:6379 slots:[0-5460] (5461 slots) master M: f56239df411d0a16a848444c7558fc275fdfb8f3 10.10.0.102:6379 slots:[5461-10922] (5462 slots) master M: 3681759047207adbb2dc8bd3cf821c525016b82e 10.10.0.103:6379 slots:[10923-16383] (5461 slots) master S: 3d93d577776d88aea8276779ef772cbae2aea2af 10.10.0.104:6379 replicates 3681759047207adbb2dc8bd3cf821c525016b82e S: f756af3c4dbf8e22b9fae6fbf749593d70f1b592 10.10.0.105:6379 replicates d8710299ca28d14163ea3ecb0427441245a77019 S: a39b1062bc97ef86d9b192676752122e7922fb19 10.10.0.106:6379 replicates f56239df411d0a16a848444c7558fc275fdfb8f3 Can I set the above configuration? (type 'yes' to accept): yes \u0026gt;\u0026gt;\u0026gt; Nodes configuration updated \u0026gt;\u0026gt;\u0026gt; Assign a different config epoch to each node \u0026gt;\u0026gt;\u0026gt; Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join ... \u0026gt;\u0026gt;\u0026gt; Performing Cluster Check (using node 10.10.0.101:6379) M: d8710299ca28d14163ea3ecb0427441245a77019 10.10.0.101:6379 slots:[0-5460] (5461 slots) master 1 additional replica(s) S: f756af3c4dbf8e22b9fae6fbf749593d70f1b592 10.10.0.105:6379 slots: (0 slots) slave replicates d8710299ca28d14163ea3ecb0427441245a77019 S: 3d93d577776d88aea8276779ef772cbae2aea2af 10.10.0.104:6379 slots: (0 slots) slave replicates 3681759047207adbb2dc8bd3cf821c525016b82e M: f56239df411d0a16a848444c7558fc275fdfb8f3 10.10.0.102:6379 slots:[5461-10922] (5462 slots) master 1 additional replica(s) M: 3681759047207adbb2dc8bd3cf821c525016b82e 10.10.0.103:6379 slots:[10923-16383] (5461 slots) master 1 additional replica(s) S: a39b1062bc97ef86d9b192676752122e7922fb19 10.10.0.106:6379 slots: (0 slots) slave replicates f56239df411d0a16a848444c7558fc275fdfb8f3 [OK] All nodes agree about slots configuration. \u0026gt;\u0026gt;\u0026gt; Check for open slots... \u0026gt;\u0026gt;\u0026gt; Check slots coverage... [OK] All 16384 slots covered. Cluster kurulumu tamamlandıktan sonra Cluster durumunu kontrol ediyoruz.\nredis-cli -c -p 6379 cluster nodes Her şey düzgünce yapıladırıldıysa aşağıdaki şekilde “Master/Slave” eşleşmeleri görünecektir.\nroot@redis01:~# redis-cli -c -p 6379 cluster nodes a39b1062bc97ef86d9b192676752122e7922fb19 10.10.0.106:6379@16379 slave f56239df411d0a16a848444c7558fc275fdfb8f3 0 1740867669000 2 connected 3d93d577776d88aea8276779ef772cbae2aea2af 10.10.0.104:6379@16379 slave 3681759047207adbb2dc8bd3cf821c525016b82e 0 1740867670571 3 connected f56239df411d0a16a848444c7558fc275fdfb8f3 10.10.0.102:6379@16379 master - 0 1740867670000 2 connected 5461-10922 d8710299ca28d14163ea3ecb0427441245a77019 10.10.0.101:6379@16379 myself,master - 0 1740867669000 1 connected 0-5460 f756af3c4dbf8e22b9fae6fbf749593d70f1b592 10.10.0.105:6379@16379 slave d8710299ca28d14163ea3ecb0427441245a77019 0 1740867670571 1 connected 3681759047207adbb2dc8bd3cf821c525016b82e 10.10.0.103:6379@16379 master - 0 1740867669867 3 connected 10923-16383 ","permalink":"https://kemalbiyikli.com/ubuntu-server-uzerinde-redis-cluster-kurulumu/","summary":"\u003ch3 id=\"redis-nedir\"\u003e\u003cstrong\u003eRedis Nedir?\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eRedis, verileri RAM üzerinde tutarak yüksek hızda okuma ve yazma işlemleri gerçekleştiren bir anahtar-değer (key-value) veri deposudur. Genellikle bir önbellek veya mesaj kuyruğu olarak kullanılır. Geleneksel veritabanlarına kıyasla çok daha hızlı çalıştığı için, performans gerektiren birçok uygulamada tercih edilmektedir.\u003c/p\u003e\n\u003ch4 id=\"redisin-kullanım-alanları\"\u003e\u003cstrong\u003eRedis’in Kullanım Alanları\u003c/strong\u003e\u003c/h4\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eÖnbellekleme (caching):\u003c/strong\u003e Web uygulamalarında sık kullanılan verilerin hızlı erişilebilir olmasını sağlar.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGerçek zamanlı analiz:\u003c/strong\u003e Örneğin, leaderboard veya sayfa görüntüleme sayaçları gibi işlemlerde kullanılır.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMesaj kuyruğu:\u003c/strong\u003e Verileri geçici olarak saklayarak dağıtık sistemlerde mesajlaşma altyapısı sağlar.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOturum yönetimi:\u003c/strong\u003e Kullanıcı oturumlarını verimli bir şekilde saklayarak performansı artırır.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch4 id=\"hangi-işletim-sistemlerinde-çalışır\"\u003e\u003cstrong\u003eHangi İşletim Sistemlerinde Çalışır?\u003c/strong\u003e\u003c/h4\u003e\n\u003cp\u003eRedis, \u003cstrong\u003een stabil ve performanslı şekilde Linux ortamında\u003c/strong\u003e çalışmaktadır. Ancak farklı platformlarda da belirli yöntemlerle kullanılabilir:\u003c/p\u003e","title":"Ubuntu Server Üzerinde Redis Cluster Kurulumu"},{"content":"Linux’ta dosya izinleri, dosyalara ve dizinlere kimlerin erişebileceğini ve bu erişimin nasıl olacağını belirler. Bu izinler, owner, group ve others için read write ve execute olmak üzere farklı kombinasyonlarla tanımlanabilir. Bu kombinasyonlar harflerle ya da rakamlarla yönetilebilmektedir. İlk bakışta karmaşık gibi görünse de oldukça basit ve anlaşılır bir düzen mevcuttur.\n1. Harflerle İzinler –Dosya İzinlerinin Sembolik Gösterimi Gösterimi Linux’ta her dosya ve dizin için üç tür izin vardır:\nRead (r): Dosyanın içeriğini okuma veya dizindeki dosyaları listeleme izni. Write (w): Dosyaya veri yazma veya dizinde dosya oluşturma/silme izni. Execute (x): Dosyayı çalıştırma veya dizine erişme izni. Bu izinler, üç farklı kullanıcı grubu için ayrı ayrı tanımlanır:\nOwner (u): Dosyanın sahibi olan kullanıcı. Group (g): Dosyanın ait olduğu grup. Others (o): Dosyanın sahibi veya grubunda olmayan diğer tüm kullanıcılar. Sembolik gösterimde, izinler harflerle (r, w, x) ifade edilir. İzinleri eklemek veya kaldırmak için + ve – işaretleri kullanılır.\n**u+rwx ** : Owner için read, write ve execute izni verir. **g+r ** : Group için read izni verir. **o-x ** : Others için execute iznini kaldırır. Örnekler:\nOwner (kullanıcı) için tüm izinleri verme:\nchmod u+rwx /home/kemalb/test.txt Bu komut, user için okuma, yazma ve çalıştırma izinleri verir.\nchmod g+r /home/kemalb/test.txt Bu komut, dosyanın ait olduğu gruba okuma izni verir.\n2. Sayısal Gösterim (Rakamlarla İzinler) Sayısal gösterimde, izinler üç basamaklı bir sayı ile ifade edilir. Her basamak, sırasıyla owner, group ve others için izinleri belirtir. Her izin türü bir sayısal değere karşılık gelir:\n**Read (r) ** : 4 **Write (w) ** : 2 **Execute (x) ** : 1 Bu değerler toplanarak her bir kullanıcı grubu için izinler belirlenir. Örneğin:\n**7 (4+2+1) ** : Read, Write, Execute **6 (4+2) ** : Read \u0026amp; Write. **5 (4+1) ** : Read \u0026amp; Execute. **4 ** : Read **0 ** : Hiçbir izin yok. Örnekler:\nchmod 777 /home/kemalb/test.txt Herkese tam erişim verir (read, write, execute).\nchmod 660 /home/kemalb/test.txt Owner ve group için read, write izni verir, diğerlerine hiçbir izin vermez.\n4. İzinlerin Uygulanması İzinleri düzenlemek için chmod komutu kullanılır. Bu komut, hem sembolik hem de sayısal gösterimle kullanılabilir.\nSembolik Gösterim: chmod [kim][işlem][izinler] dosya Kim: u (sahip), g (grup), o (diğerleri), a (hepsi) İşlem: + (ekle), – (kaldır), = (ayarla) İzinler: r (okuma), w (yazma), x (çalıştırma) Sayısal Gösterim: chmod [izinler] dosya İzinler: Üç basamaklı sayı (örneğin, 755, 644, 750) 5. Örnekler chmod u+rwx,g+r-x,o-rwx /home/kemalb/test.txt Sahibe tam erişim verir. Gruba okuma izni verir, çalıştırma iznini kaldırır. Diğerlerinden tüm izinleri kaldırır. chmod 750 /home/kemalb/test.txt Sahip: 7 (4+2+1) → Tam erişim. Grup: 5 (4+1) → Okuma ve çalıştırma. Diğerleri: 0 → Hiçbir izin yok. 6. Sonuç Linux’ta dosya izinleri, sistem güvenliği için kritik öneme sahiptir. İzinleri doğru şekilde yönetmek, yetkisiz erişimleri engeller ve sistemin güvenliğini artırır. Sembolik ve sayısal gösterimler, izinleri esnek bir şekilde yönetmemizi sağlar.\n","permalink":"https://kemalbiyikli.com/linuxda-dosya-izinlerinin-temel-yapisi/","summary":"\u003cp\u003eLinux’ta dosya izinleri, dosyalara ve dizinlere kimlerin erişebileceğini ve bu erişimin nasıl olacağını belirler. Bu izinler, \u003cstrong\u003eowner, group ve others\u003c/strong\u003e için \u003cstrong\u003eread\u003c/strong\u003e \u003cstrong\u003ewrite\u003c/strong\u003e ve \u003cstrong\u003eexecute\u003c/strong\u003e olmak üzere farklı kombinasyonlarla tanımlanabilir. Bu kombinasyonlar harflerle ya da rakamlarla yönetilebilmektedir. İlk bakışta karmaşık gibi görünse de oldukça basit ve anlaşılır bir düzen mevcuttur.\u003c/p\u003e\n\u003ch3 id=\"1\"\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e1. \u003cstrong\u003eHarflerle İzinler\u003c/strong\u003e\u003c/strong\u003e –\u003cstrong\u003eDosya İzinlerinin Sembolik Gösterimi Gösterimi\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eLinux’ta her dosya ve dizin için üç tür izin vardır:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRead (r):\u003c/strong\u003e Dosyanın içeriğini okuma veya dizindeki dosyaları listeleme izni.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWrite (w):\u003c/strong\u003e Dosyaya veri yazma veya dizinde dosya oluşturma/silme izni.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExecute (x):\u003c/strong\u003e Dosyayı çalıştırma veya dizine erişme izni.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBu izinler, üç farklı kullanıcı grubu için ayrı ayrı tanımlanır:\u003c/p\u003e","title":"Linux’da Dosya İzinlerinin Temel Yapısı"},{"content":"Linux sunucular, özellikle disk yönetimi söz konusu olduğunda oldukça esnek bir yapı sunar. Bu yapı karmaşık gibi görünse de aslında basit bir mantığın üzerine inşa edilmiştir. Linux sistemlerde yaygın bir şekilde kullanılan LVM (Logical Volume Manager) sayesinde, sunucunuzun disk alanını dinamik olarak yönetebilir ve ihtiyaç duyduğunuzda belirli bölümleri kolayca genişletebilirsiniz. Bu yazıda, RedHat tabanlı bir sunucuda /home dizinini 30GB artırma işlemini adım adım anlatacağım.\n1-Disk Durumunun Kontrolü Sunucuda diskimizin durumu aşağıdaki gibidir.\n[root@hometst ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 98G 0 part ├─rhel-root 253:0 0 89G 0 lvm / ├─rhel-swap 253:1 0 8G 0 lvm [SWAP] └─rhel-home 253:2 0 21G 0 lvm /home sdb 8:16 0 100G 0 disk └─rhel-home 253:2 0 21G 0 lvm /home sr0 11:0 1 1024M 0 rom Yukarıdaki çıktıya göre, /home dizini 21GB alana sahip. Genişletme işlemi için disk boyutunun artırılması gerekiyor. Sunucumuzda diskler vCenter üzerinden yönetiliyor, bu yüzden genişleteceğimiz diskin hangi fiziksel diske karşılık geldiğini tespit etmemiz gerekiyor.\nBu bilgiyi aşağıdaki komutla edinebiliriz:\nlsblk -o NAME,HCTL,SIZE,MOUNTPOINT HCTL sütunu, fiziksel diskin bağlı olduğu controller ve disk numarasını gösterir. Böylece vCenter üzerinde hangi iSCSI bağlantısına sahip olduğunu görebiliriz. Gerekli diski tespit ettikten sonra vCenter üzerinden genişletme işlemini gerçekleştireceğiz.\n2: vCenter’da Diski Genişletme vCenter‘a giriş yapıp diskini artıracağımız VM‘i buluyoruz.\nSanal makinenizde Edit Settings altında tespit ettiğimiz diski buluyoruz.\nsdb diskine karşılık gelen diski en az 30 GB artırın.\n3-Physical Volume’u Genişletme Disk boyutunu artırdıktan sonra, sunucuyu yeniden başlatmadan diskin büyüdüğünü tanıtmak için şu komutu çalıştırın:\necho 1 \u0026gt; /sys/block/sdb/device/rescan Diski genişlettikten sonra, Physical Volume’ü yeniden boyutlandırmak için şu komutu çalıştırın.\npvresize /dev/sdb Yeni disk boyutunu kontrol etmek için lsblk komutunu kullanın. sdb diskinin artık 130GB olduğunu görmelisiniz.\n4-Logical Volume’u Genişletme sdb diskini 130GB olarak gördükten sonra, vgs komutunu çalıştırarak volume group’ta kullanılabilir boş alanı kontrol edebilirsiniz.\n/home dizini için ayrılan volume group’u genişletmek amacıyla aşağıdaki komutu kullanın. Bu komut, rhel-home dizinini 30GB büyütecektir:\nlvextend -L+30G /dev/mapper/rhel-home Alternatif olarak, kullanılabilir tüm boş alanı kullanmak için şu komutu da tercih edebilirsiniz:\nlvextend -l +100%FREE /dev/mapper/rhel-home Bu komutu çalıştırdıktan sonra lsblk ile kontrol edin. /home dizininin 51GB olduğunu görmelisiniz.\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 98G 0 part ├─rhel-root 253:0 0 89G 0 lvm / ├─rhel-swap 253:1 0 8G 0 lvm [SWAP] └─rhel-home 253:2 0 51G 0 lvm /home sdb 8:16 0 130G 0 disk └─rhel-home 253:2 0 51G 0 lvm /home sr0 11:0 1 1024M 0 rom 5-Dosya Sistemini Genişletme Ancak, df -h komutu ile kontrol ettiğinizde /home dizini hala 21GB olarak görebilirsiniz. /home dizininin yeni ayrılan alanı kullanabilmesi için dosya sistemini de genişletmeniz gerekiyor. Öncelikle dosya sisteminin türünü kontrol etmek için şu komutu çalıştırın:\ndf -T /home Bu komutun çıktısında dosya sisteminin xfs ya da ext4 olduğunu göreceksiniz.\nXFS Dosya Sistemi İçin:\nEğer dosya sisteminiz XFS ise, aşağıdaki komutla genişletme işlemini gerçekleştirebilirsiniz:\nxfs_growfs /home EXT4 Dosya Sistemi İçin:\nEğer dosya sisteminiz ext4 ise, aşağıdaki komutu kullanarak dosya sistemini genişletebilirsiniz:\nresize2fs /dev/mapper/rhel-home Dosya sistemini genişlettikten sonra df -h komutunu tekrar çalıştırın. Artık /home dizininin 51GB olduğunu görmelisiniz.\n[root@hometst ~]# df -h NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 98G 0 part ├─rhel-root 253:0 0 89G 0 lvm / ├─rhel-swap 253:1 0 8G 0 lvm [SWAP] └─rhel-home 253:2 0 51G 0 lvm /home sdb 8:16 0 130G 0 disk └─rhel-home 253:2 0 51G 0 lvm /home sr0 11:0 1 1024M 0 rom Yukarıdaki adımları takip ederek, Linux sunucularda LVM dizinlerini herhangi bir restart veya kesinti gerekmeksizin genişletebilirsiniz.\n","permalink":"https://kemalbiyikli.com/lvm-ile-linux-sunucuda-disk-genisletme/","summary":"\u003cp\u003eLinux sunucular, özellikle disk yönetimi söz konusu olduğunda oldukça esnek bir yapı sunar. Bu yapı karmaşık gibi görünse de aslında basit bir mantığın üzerine inşa edilmiştir. Linux sistemlerde yaygın bir şekilde kullanılan \u003cstrong\u003eLVM (Logical Volume Manager)\u003c/strong\u003e sayesinde, sunucunuzun disk alanını dinamik olarak yönetebilir ve ihtiyaç duyduğunuzda belirli bölümleri kolayca genişletebilirsiniz. Bu yazıda, \u003cstrong\u003eRedHat\u003c/strong\u003e tabanlı bir sunucuda \u003ccode\u003e/home\u003c/code\u003e dizinini \u003cstrong\u003e30GB\u003c/strong\u003e artırma işlemini adım adım anlatacağım.\u003c/p\u003e\n\u003ch3 id=\"1-disk-durumunun-kontrolü\"\u003e\u003cstrong\u003e1-Disk Durumunun Kontrolü\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eSunucuda diskimizin durumu aşağıdaki gibidir.\u003c/p\u003e","title":"LVM ile Linux Sunucuda Disk Genişletme"},{"content":"Geçtiğimiz aylarda bir firmayı oldukça eski bir Hyper-V ortamından güncel bir VMware ortamına geçirmemiz gerekti. Bu işlemi en pürüzsüz şekilde nasıl yaparım diye araştırırken en başta aklıma vCenter Converter geldi. Kurulumunu yaptım ve çeşitli testler yaptım, adım adım hataları giderdim ancak ne olursa olsun bu işlem hayallerinizdeki gibi gerçekleşmiyor. Her zaman ufak tefek de olsa bir yerlerde sorun çıkıyor. Sunucunun UUID değiştiği için bazı servisler bozulabiliyor, güvenlikle ilgili Group Policy’lere takılabiliyor, network kartını tanımıyor, taşıyacağınız her sunucuda güvenlik yazılımlarını disable etmeniz gerekiyor, bu da sürecin uzamasına neden oluyor. Bu ve benzeri sorunlarla uğraştığınızda da bu sürecin istediğiniz gibi gerçekleşmeyeceğini anlıyorsunuz. Bu noktada alternatif çözümleri araştırdıktan sonra bu geçiş sürecinde veeam kullanmaya karar verdim.\nÖncelikle neden Veeam’de karar kıldığımı aktarayım.\n1- Sunucularımın UUID’si değişmediği için olası bir çok sorunun da önüne geçmiş oldum.\n2- Backup restore mantığında bir taşıma olacağı için sunucudaki uygulamalar veya policy’lerle ilgili bir işlem yapmam gerekmiyor.\nKurulum ve Yapılandırma\n1- Yeni kurduğum VMware ortamında sanal sunucu olarak Veeam kurulumunu gerçekleştirdim. Dilerseniz fiziksel bir proxy sunucusu da konumlandırarak backupları SAN üzerinden de alabilirsiniz. Bu sizin network ve storage alt yapınıza göre tercih edeceğiniz bir durum. Benim Hyper-V ve VMware ortamımdaki management network’um 10G olduğu için network üzerinden backup almayı tercih ettim.\n2- Backup Repository’leri için sunucuya sanallaştırma ortamında yeni bir disk verdim ve bu diski Windows ortamında REFS olarak yapılandırdım. Devamında bu diski Veeam’de backup repository olarak yapılandırdım.\n3- Sunucunun networkünü 10G olarak yapılandırdım. Sunucuyu VMware ortamına geçirirken migration işlemini network üzerinden yapacağımız için sunucuya esxi hostlarımın vMotion Network’ü ile aynı IP bloğundan bir IP adresi verdim.\n4- Eski Hyper-V Failover Cluster ortamımı ve yeni VMware ortamımı Veeam’e Hyper-V Failover Cluster olarak ekledim. Bir Hyper-V Failover Cluster ortamınızı Veeam’e eklemek istediğiniz Access Denied hatası ile karşılaşabilirsiniz. Keza ben de aynı şekilde access denied hatasıyla karşılaştım. Genelde birçok insan bu aşamada hata aldığı için her bir node’u ayrı olarak ekleme yoluna gitmiş. Ancak Windows update’lerini eksiksiz bir şekilde yaptığınızda bu hatadan kurtulabilirsiniz.\n5- Taşıma işlemi aynı site ve network yapısı içerisinde olacağı için herhangi bir Proxy sunucusu yapılandırmadım.\nSunucu Migration\nİşlemi iki farklı senaryoda gerçekleştirebiliriz. Sunucuyu kapatma ile ilgili bir sorununuz yoksa direk kapatıp Full Backup alıp işlemlere başlayabilirsiniz. Ya da benim senaryomda olduğu gibi minimum kesintiye ihtiyaç duyuyorsanız eğer Full Backup aldıktan sonra taşıma yapacağınız saatte sunucuyu kapatıp Incremental Backup aldıktan sonra taşımayı gerçekleştirebilirsiniz. Benimki gibi bir senaryoda sırası ile aşağıdaki adımları gerçekleştirebilirsiniz.\nÖncelikle aşağıdaki gibi Instant Recovery kullanarak sunucumuzu convert ediyoruz.\n1- Taşınacak sunucu için bir Backup Job oluşturuyoruz ve Full Backup başlatıyoruz.\n2- Full backup işlemi tamamlandıktan sonra taşıma işlemini gerçekleştireceğimiz esnada data kaybı olmaması için sunucuyu kapatıp Incremental Backup başlatıyorum.\n3- Backup işlemi tamamlandıktan sonra Instant Recovery işlemini başlatıyorum. Burada sunucuyu Backup diski üzerinden VMware ortamınıza deploy edecektir, isterseniz sunucuyu Power On yapabilirsiniz. Ancak sunucuyu açtığınızda Migration işlemi daha da uzayacaktır. Bu nedenle Instant Recovery tamamlandıktan sonra sağ tıklayıp Migrate to Production seçeneğini seçiyorum.\n4- Destination bölümünde Instant Recovery işlemini yapacağımız sunucumuzun ismini, taşıyacağımız hostumuzu, networkümüzü belirliyoruz. Bu aşamada networkü seçmiş olsak dahi taşıma işleminin ardından sunucumuz networkle haberleşmeyecektir. Taşıma işlemi sonrasında network kartını yeniden vmxnet3 olarak ekleyip tanıtmanız gerekiyor. (Bu durum her koşulda bir zorunluluk, mevcutta kullandığınız Hyper-V network adapter VMware ile çalışmayacağı için yeni bir adapter ekleyip config yapmak icap ediyor.)\n5- Finish diyerek Instant Recovery işlemini başlatıyoruz. Bu aşamada yukarıda da belirttiğim gibi migration tamamlanmadan VM’i power on yapmıyorum. Aksi halde migration aşaması oldukça uzuyor.\n6- Instant Recovery işlemini yaptıktan sonra artık sunucuyu vSphere ortamınızda görebilirsiniz. Sunucumuz şu an Veeam tarafından vSphere üzerinde çalıştırılabilir şekilde convert edildi. Ancak henüz taşıma işlemini gerçekleştirmedik.\n7- Taşıma işlemini tamamlamak için Migrate to Production seçeneğini kullanıyoruz. Böylelikle Veeam Repository’imiz üzerindeki VM’imizi vSphere ortamına taşımaya başlıyoruz.\n8- Destination bölümünde sunucumuzu migrate edeceğimiz host ve datastore’u seçiyoruz.\n9- Transfer bölümünde proxy kullanıyorsak eğer proxy sunucularımızı seçiyoruz ve finish diyerek taşıma işlemini başlatıyoruz.\nBu aşmada taşıma işlemimiz tamamlanmış oluyor. Artık Hyper-V üzerinde çalışan sanal sunucumuz vSphere üzerinde çalışmabilecek şekilde convert edildi.\nBu nokta yapmamız gereken tek bir işlem kalıyor. Sunucumuz daha önceden Hyper-V sürücüleri ile çalıştığı için convert sonrasında network kartımız çalışmaz hale geliyor. Sunucumuza VMXNET 3 olarak yeni bir network kartı ekliyoruz Web Console üzerinden bağlanarak VMware Tools kurulumu yapıyoruz. Sunucumuza restart attıktan sonra Windows üzerinden IP Subnet gibi ayarları tekrar yaptıktan sonra geçmiş olsun diyoruz.\n","permalink":"https://kemalbiyikli.com/hyper-v-to-vsphere-migration/","summary":"\u003cp\u003eGeçtiğimiz aylarda bir firmayı oldukça eski bir Hyper-V ortamından güncel bir VMware ortamına geçirmemiz gerekti. Bu işlemi en pürüzsüz şekilde nasıl yaparım diye araştırırken en başta aklıma vCenter Converter geldi. Kurulumunu yaptım ve çeşitli testler yaptım, adım adım hataları giderdim ancak ne olursa olsun bu işlem hayallerinizdeki gibi gerçekleşmiyor. Her zaman ufak tefek de olsa bir yerlerde sorun çıkıyor. Sunucunun UUID değiştiği için bazı servisler bozulabiliyor, güvenlikle ilgili Group Policy’lere takılabiliyor, network kartını tanımıyor, taşıyacağınız her sunucuda güvenlik yazılımlarını disable etmeniz gerekiyor, bu da sürecin uzamasına neden oluyor. Bu ve benzeri sorunlarla uğraştığınızda da bu sürecin istediğiniz gibi gerçekleşmeyeceğini anlıyorsunuz. Bu noktada alternatif çözümleri araştırdıktan sonra bu geçiş sürecinde veeam kullanmaya karar verdim.\u003c/p\u003e","title":"Hyper-V to vSphere Migration"},{"content":"VMware vSphere site to site replication’dan bir sunucuyu kaldırdığınızda ya da VSRM sunucusunu kaybettiğinizde ve replikasyonlarınız dağıldığında VM’leriniz olduğu gibi çalışacaktır. Ancak sunucularınızda disk artırmak istediğinizde Cannot increase disk size due to old replication participation hatası ile karşılaşmanız muhtemel.\nSunucuda power on veya power off fark etmeksizin disk kapasitesini artırmak istediğinizde fail olacaktır. Bu problemin çözümünü araştırdığımda ise VMware’in KB’lerini incelediğimde de bir çözüme ulaşamadım. Forumlarda çeşitli çözümler okudum, sizlerle de başarılı olduğum bir çözümü çözümü paylaşmak istiyorum.\nYaygın olarak iki çözümle karşılaştım.\nBunlardan birincisi;\nSunucuyu power off yapıyoruz. Delete form inventory ile sunucuyu vCenter’dan kaldırıyoruz. Datastore’da sunucunun dosyalarının olduğu dizine gidiyoruz ve RDID dosyasını siliyoruz. Sunucuyu .vmx dosyasından tekrar register ediyoruz. Bu yöntemde hem sunucuda kesinti yapmanız gerekiyor. Ek olarak bu yöntem maalesef bende problemi gidermedi.\nİkinci yöntem;\nBu yöntemde sanal sunucuyu kapatmamız gerekmiyor ve yapacağımız işlemler herhangi bir kesintiye de sebep olmuyor. İşlemleri aşağıdaki sıralama ile gerçekleştiriyoruz.\nSanal sunucunun bulunduğu esxi host’da SSH’ı aktif ediyoruz. Ardından host’a SSH ile bağlanıyoruz ve aşağıdaki komutları sırası ile çalıştırıyoruz. vim-cmd vmsvc/getallvms Bu komut ile host üzerinde bulunan sanal sunucuları listeliyoruz. En soldaki sütun sanal sunucunun VM ID’sini göstermektedir. Listeden sorun yaşadığımız sanal sunucuyu buluyoruz ve ID’sini bir kenara not ediyoruz. Benim sunucu ID’im 219 vim-cmd hbrsvc/vmreplica.getConfig 219 Komutunu çalıştırarak sanal sunucuda replikasyonun aktif durumda olduğunu görüyoruz. vim-cmd hbrsvc/vmreplica.disable 219 Komutunu çalıştırarak bu sunucu için replikasyonu disable ediyoruz. İşlemi tamamladıktan sonra vim-cmd hbrsvc/vmreplica.getConfig 219 komutu ile replikasyonun disable olduğunu görebilirisiniz. Bu işlemlerin ardından sunucunuzda disk artırımını gerçekleştirebilirsiniz.\n","permalink":"https://kemalbiyikli.com/cannot-increase-disk-size-due-to-old-replication-participation-hatasi-ve-cozumu/","summary":"\u003cp\u003eVMware vSphere site to site replication’dan bir sunucuyu kaldırdığınızda ya da VSRM sunucusunu kaybettiğinizde ve replikasyonlarınız dağıldığında VM’leriniz olduğu gibi çalışacaktır. Ancak sunucularınızda disk artırmak istediğinizde \u003cstrong\u003e\u003ccode\u003eCannot increase disk size due to old replication participation \u003c/code\u003e\u003c/strong\u003e hatası ile karşılaşmanız muhtemel.\u003c/p\u003e\n\u003cp\u003eSunucuda power on veya power off fark etmeksizin disk kapasitesini artırmak istediğinizde fail olacaktır. Bu problemin çözümünü araştırdığımda ise VMware’in KB’lerini incelediğimde de bir çözüme ulaşamadım. Forumlarda çeşitli çözümler okudum, sizlerle de başarılı olduğum bir çözümü çözümü paylaşmak istiyorum.\u003c/p\u003e","title":"“Cannot increase disk size due to old replication participation” hatası ve çözümü"},{"content":"Bu yazımda DELL EMC Data Domain 6300‘ün firmware upgrade işleminden söz edeceğim.\nUpgrade işlemini yapacağım ürün oldukça eski bir sürümde kalmış. Bu nedenle son sürüm olan 7.13.0.20’ye geçebilmem için cihazımın minimum 6.2 sürümünde olması gerekiyor. Bu yüzden önce 6.2 sürümüne ardından da 7.0.13 sürümüne upgrade işlemi gerçekleştireceğim.\nİşlemlerin sırası ile nasıl yapıldığına geçmeden önce belirtmem gereken bazı maddeler var.\nBu işlem tamamlandıktan sonra otomatik reboot işlemi gerçekleşecektir ve bu süre bende her bir upgrade işlemi için yaklaşık 40 dk. kadar sürdü. Bu nedenle kesinti için bir planlama yapmanız gerekebilir.\nUpgrade esnasında herhangi bir problemle karşılaşmadım, karşılaşsam da ürünü tamamen sıfırladığım ve içi boş olduğu için zarar görecek kritik bir veri bulunmuyordu. Bu nedenle olası bir problem benim açımdan bir sorun teşkil etmiyordu. Ancak sizler ürünü hali hazırda kritik verileriniz ile kullanıyorsanız profesyonel bir yardım almanız yararınıza olacaktır.\nGelelim upgrade işlemnine\nÖncelikle ürünün sayfasından ihtiyacımız olan paketleri download ediyoruz.\nBen ihtiyacım olan 6.2.1.110 ve 7.13.0.20 sürümlerini download ediyorum.\nİndirdiğimiz paketleri de web arayüzünden yüklememiz gerekiyor ancak ben bu aşamada aşağıdaki hatayı aldım.\nBu aşamada internette çeşitli araştırmalar yaptım ancak hata ile ilgili spesifik bir çözüme ulaşamadım. Shamistan ARZIMANLI‘nın bir yazısında aynı hatayla karşılaştığını ve alternatif olarak FTP kullandığını gördüm. Ben de aynı şekilde upgrade dosylarını FTP ile atma yolunu tercih ettim. Bu işlem için de WinSCP uygulamasını kullandım.\nWinSCP ile DataDomain’e FTP protokolü ile bağlandım. rpm dosyalarını Data Domain’in root/releases dizinine kopyaladım.\nKopyalama işlemi tamamlandıktan sonra web arayüzünde Maintenance/System altında aşağıdaki gibi paketinizi görüntüleyebilirsiniz.\nUpgrade öncesinde dosyamızı işaretleyip UPGRADE-PRECHECK seçeneğini seçiyoruz ve paketimiz eksiksiz ve uygun olup olmadığını kontrol ediyoruz.\nPrecheck işlemi sorunsuz bir şekilde tamamlandıktan sonra PERFORM SYSTEM UPGRADE butonu ile upgrade işlemine başlayabiliriz.\nUpgrade’in yüklenmesi hızlıca bitiyor ancak reboot işlemi yazının başında da belirttiğim gibi biraz zaman alıyor. Upgrade işlemi tamamlandığında yeni sürümümüz bizleri karşılıyor.\nBir sonraki aşamada 7.13.0.20 sürüme upgrade yapıyorum. Bu işlem için de süreç aynı işliyor.\n","permalink":"https://kemalbiyikli.com/dell-emc-dd6300-firmware-upgrade/","summary":"\u003cp\u003eBu yazımda \u003cstrong\u003eDELL EMC Data Domain 6300\u003c/strong\u003e‘ün firmware upgrade işleminden söz edeceğim.\u003c/p\u003e\n\u003cp\u003eUpgrade işlemini yapacağım ürün oldukça eski bir sürümde kalmış. Bu nedenle son sürüm olan 7.13.0.20’ye geçebilmem için cihazımın minimum 6.2 sürümünde olması gerekiyor. Bu yüzden önce 6.2 sürümüne ardından da 7.0.13 sürümüne upgrade işlemi gerçekleştireceğim.\u003c/p\u003e\n\u003cp\u003eİşlemlerin sırası ile nasıl yapıldığına geçmeden önce belirtmem gereken bazı maddeler var.\u003c/p\u003e\n\u003cp\u003eBu işlem tamamlandıktan sonra otomatik reboot işlemi gerçekleşecektir ve bu süre bende her bir upgrade işlemi için yaklaşık 40 dk. kadar sürdü. Bu nedenle kesinti için bir planlama yapmanız gerekebilir.\u003c/p\u003e","title":"DELL EMC DD6300 Firmware Upgrade"},{"content":"\nvCenter’ınızı upgrade etmek istediğinizde yukarıdaki gibi bir hatayla karşılaşıyorsanız büyük ihtimalle 6.5 öncesi bir sürümü upgrade etmeye çalışıyorsunuzdur. Bu hata vCenter üzerinde aynı isme sahip olan birden fazla Port Group’a sahip olmanızdan kaynaklanıyor.\nBu problem vCenter 6.5 ile giderildi, Patch Note‘larını inceleyebilirsiniz.\nBu problemi mevcut sürümünüzde gidermek ve upgrade yapabilmeniz için VMware’in bir KB‘si bulunuyor. Ancak KB’yi incelerseniz eğer vCenter Database’ine bağlanmanız, ilgili satır ve sütunları tespit ederek birtakım işlemler uygulamanız gerektiğini göreceksiniz. Ancak daha basit bir şekilde çözmek de mümkün.\nÖncelikle bu hataya neden olan Port Group’ları tespit etmemiz gerekiyor. Eğer çok fazla Port Group yoksa bunu kendiniz vCenter üzerinde elle de yapabilirsiniz. Tespit ettiğiniz Port Group’ların isimlerini değiştirdiğinizde ya da sildiğinizde probleminiz çözülecektir. Peki ya benim gibi yüzlerce Port Group’unuz varsa?\nBunun için VMware’in önerdiği yöntemi tercih etmem bir seçenekti ancak ben farklı bir yoldan giderek ortamımın bir RVTools raporunu aldım, Excel’de duplicate hücreleri işaretleyerek aynı isimdeki Port Group’ları tespit ettim ve düzelttim.\n","permalink":"https://kemalbiyikli.com/vcenter-upgrade-source-vcenter-has-duplicate-names-in-a-network-folder-hatasi/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/vcenter-duplicate-names/vcenter-duplicate-names-1.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003evCenter’ınızı upgrade etmek istediğinizde yukarıdaki gibi bir hatayla karşılaşıyorsanız büyük ihtimalle 6.5 öncesi bir sürümü upgrade etmeye çalışıyorsunuzdur. Bu hata vCenter üzerinde aynı isme sahip olan birden fazla Port Group’a sahip olmanızdan kaynaklanıyor.\u003c/p\u003e\n\u003cp\u003eBu problem vCenter 6.5 ile giderildi, \u003ca href=\"https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-650b-release-notes.html\"\u003ePatch Note\u003c/a\u003e‘larını inceleyebilirsiniz.\u003c/p\u003e\n\u003cp\u003eBu problemi mevcut sürümünüzde gidermek ve upgrade yapabilmeniz için VMware’in bir \u003ca href=\"https://kb.vmware.com/s/article/2147547\"\u003eKB\u003c/a\u003e‘si bulunuyor. Ancak KB’yi incelerseniz eğer vCenter Database’ine bağlanmanız, ilgili satır ve sütunları tespit ederek birtakım işlemler uygulamanız gerektiğini göreceksiniz. Ancak daha basit bir şekilde çözmek de mümkün.\u003c/p\u003e","title":"vCenter Upgrade: Source vCenter has Duplicate Names in a Network Folder Hatası"},{"content":"ESXi upgrade işlemi birden fazla yöntemle yapılabilmektedir, bu yazımda cli üzerinden esxi upgrade işleminin nasıl yapılacağını aktaracağım.\nBunun için aşağıdaki adımları takip etmemiz gerekmektedir. Öncelikle offline bundle paketini customerconnect.vmware.com adresinden download ediyoruz. Download ederken custom bir esxi sürümü mü standart bir esxi sürümü mü kullandığımıza dikkat etmemiz gerekiyor. Ben standart sürüm kullandığım için standart sürümü tercih ediyorum.\nUygun sürümü download ettikten sonra upgrade işlemini yapacağız esxi hosta bağlı olan bir datastore’a upload ediyoruz.\nArdından hostumuzda SSH’ı aktif ediyoruz.\nHostumuzu maintenance moda almadan önce dikkat etmemiz gereken bazı noktalar var.\nEğer hostumuz standalone çalışıyorsa maintenace mod aktif olduğunda sunucularımız power off duruma geçecektir. Host bir vCenter ortamında yönetiliyor ve clustera dahil ise üzerindeki sunucuları vMotion ile diğer sunuculara dağılacaktır. Ancak sunucuları diğer hostlara manuel olarak taşımak oluşabilecek migration hatalarının önüne geçmemizi sağlayacaktır. Kontrollerimizi yaptıktan sonra putty vb. bir programla hostumuza bağlanıyoruz.\nHostumuzu maintenace moda almak için de aşağıdaki komutu çalıştırıyoruz.\nvim-cmd hostsvc/maintenance_mode_enter Hostumuzu maintenance moda aldıktan sonra update komutunu çalıştırabilmek için upgrade dosyasının profil bilgisine ihtiyacımız. Bu bilgiyi elde etmek için aşağıdaki komutu çalıştırıyoruz. Komut büyük küçük harfe karşı duyarlı. Bu nedenle datastore ismini ve dosya ismini yazarken dikkat etmek gerekiyor.\nesxcli software sources profile list -d /vmfs/volumes/DATASTORE01/VMware-ESXi-8.0-20513097-depot.zip Komutu çalıştırdıktan sonra aşağıdaki görselde gördüğümüz profil bilgisini kopyalıyoruz ve upgrade komutunu aşağıdaki şekilde düzenliyoruz.(Resim 3)\nesxcli software profile update -p ESXi-8.0.0-20513097-standard -d /vmfs/volumes/DATASTORE01/VMware-ESXi-8.0-20513097-depot.zip Yukarıda düzenlediğimiz komutu çalıştıyoruz ve upgrade işlemini gerçekleştiriyoruz. Upgrade sonrasında bizden restart isteyecektir. Hostumuzu aşağıdaki komutla maintenance modundan çıkartıp restart ederek ve upgrade işlemi tamamlıyoruz.\nvim-cmd hostsvc/maintenance_mode_exit ","permalink":"https://kemalbiyikli.com/esxi-cli-upgrade/","summary":"\u003cp\u003eESXi upgrade işlemi birden fazla yöntemle yapılabilmektedir, bu yazımda cli üzerinden esxi upgrade işleminin nasıl yapılacağını aktaracağım.\u003c/p\u003e\n\u003cp\u003eBunun için aşağıdaki adımları takip etmemiz gerekmektedir. Öncelikle offline bundle paketini \u003ca href=\"http://customerconnect.vmware.com\"\u003ecustomerconnect.vmware.com\u003c/a\u003e adresinden download ediyoruz. Download ederken custom bir esxi sürümü mü standart bir esxi sürümü mü kullandığımıza dikkat etmemiz gerekiyor. Ben standart sürüm kullandığım için standart sürümü tercih ediyorum.\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/esxi-cli-upgrade/esxi-cli-upgrade-1.png\"\u003e\u003c/p\u003e\n\u003cp\u003eUygun sürümü download ettikten sonra upgrade işlemini yapacağız esxi hosta bağlı olan bir datastore’a upload ediyoruz.\u003c/p\u003e","title":"VMware ESXi CLI Upgrade 7.0\u003e8.0"},{"content":"Selamlar, ben Kemal, kendimi 1992 İstanbul doğumlu, evli ve bir çocuk babası bir teknoloji tutkunu biri olarak tanımlasam aslında çok da yanlış olmaz. Uludağ Üniversitesi Psikolojik Danışmanlık ve Rehberlik bölümü mezunuyum. Bir süre okuduğum bölüme uygun bir meslek icra etmiş olsam da kariyerime bilişim sektöründe sunucu sanallaştırma, depolama ve yedekleme alanlarında devam ediyorum.\nSektör değişikliği yaptığım süreçte birçok arkadaşımızın bloglarından, onların oluşturdukları topluluk sayfalarından çokça istifade ettim, aslında kişisel blog’umu açmamın temelinde yatan sebeplerden birisi de bu. Edindiğim tecrübeyi, tuttuğum ve değerli gördüğüm notlarımı, ipuçlarını vs. bu blog altından paylaşmayı amaçlıyorum.\nBu blog altında paylaştığım yazılar üreticiler ve ürünleri üzerine olacaktır; bazı içerikler zamanla geçerliliğini yitirebilir bu nedenle uygulamak ve test etmek sizin sorumluluğunuzdadır.\nİçeriklerimi sitenizde sosyal medyada ve çeşitli mecralarda kaynak göstererek kullanabilirsiniz.\nÖneri ve görüşleriniz için bana ulaşabilirsiniz.\nSaygılar ve sevgiler.\n","permalink":"https://kemalbiyikli.com/hakkimizda/","summary":"\u003cp\u003eSelamlar, ben Kemal, kendimi 1992 İstanbul doğumlu, evli ve bir çocuk babası bir teknoloji tutkunu biri olarak tanımlasam aslında çok da yanlış olmaz. Uludağ Üniversitesi Psikolojik Danışmanlık ve Rehberlik bölümü mezunuyum. Bir süre okuduğum bölüme uygun bir meslek icra etmiş olsam da kariyerime bilişim sektöründe \u003cstrong\u003esunucu sanallaştırma, depolama ve yedekleme\u003c/strong\u003e alanlarında devam ediyorum.\u003c/p\u003e\n\u003cp\u003eSektör değişikliği yaptığım süreçte birçok arkadaşımızın bloglarından, onların oluşturdukları topluluk sayfalarından çokça istifade ettim, aslında kişisel blog’umu açmamın temelinde yatan sebeplerden birisi de bu. Edindiğim tecrübeyi, tuttuğum ve değerli gördüğüm notlarımı, ipuçlarını vs. bu blog altından paylaşmayı amaçlıyorum.\u003c/p\u003e","title":"Hakkımda"}]