SEWA / RENTAL MOBIL Toyota HIACE Commuter dengan harga murah di kota CIREBON merupakan salah satu pilihan yang tepat bagi para Traveller, karena memiliki kapasitas 15 penumpang. Anda dapat merasakan semua kemewahan dan kenyamanan Toyota HIACE Commuter ini dengan biaya yang murah melalui HIACE CIREBON Trans, kami juga menyediakan paket tour wisata untuk kota CIREBON dan sekitarnya, Beberapa kota sekitar CIREBON serta drop atau penjemputan penumpang untuk beberapa kota, antar jemput stasiun Kereta api, atau Bandara...
Untuk Info Pemesanan
lihat link kami di : HIACE CIREBON Trans - Rental Cirebon http://cirebonrenthiace.blogspot.com/
O documento discute os conceitos fundamentais de Domain-Driven Design (DDD): (1) Ubiquitous Language é uma linguagem comum entre especialistas técnicos e de domínio; (2) Domain Model é um modelo conceitual do domínio que representa visões de negócio e técnicas; (3) Patterns são soluções para problemas recorrentes que ligam o Domain Model à implementação.
The document discusses Cisco VPN solutions, including an introduction to IPSec and IPSec VPN topologies. It provides information on Cisco site-to-site VPN solutions and the basics of initiating an IPSec session through phase one and two negotiations. It also briefly summarizes encrypting and decrypting packets, rebuilding security associations, and provides a simple IPSec configuration example.
[ 2018 컨테이너 기술의 모든 것 ] NBP 박기은 CTO 세션에서 소개된 네이버 클라우드 플랫폼의 컨테이너 기술 관련 서비스 및 향후 로드맵을 공유합니다.
[ 2018 All About Container ] Presentation about container technology & service roadmap of NAVER CLOUD PLATFORM by NBP cloud solution CTO "Park Ki Eun"
This document discusses the different layers and types of cloud computing as defined by NIST, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). IaaS provides on-demand provisioning of servers and infrastructure resources over the internet. PaaS provides development platforms and tools to build and run applications remotely without having to manage the underlying infrastructure. SaaS provides software applications that users can access over the internet through a web browser or mobile device without installing or maintaining the software.
SEWA / RENTAL MOBIL Toyota HIACE Commuter dengan harga murah di kota CIREBON merupakan salah satu pilihan yang tepat bagi para Traveller, karena memiliki kapasitas 15 penumpang. Anda dapat merasakan semua kemewahan dan kenyamanan Toyota HIACE Commuter ini dengan biaya yang murah melalui HIACE CIREBON Trans, kami juga menyediakan paket tour wisata untuk kota CIREBON dan sekitarnya, Beberapa kota sekitar CIREBON serta drop atau penjemputan penumpang untuk beberapa kota, antar jemput stasiun Kereta api, atau Bandara...
Untuk Info Pemesanan
lihat link kami di : HIACE CIREBON Trans - Rental Cirebon http://cirebonrenthiace.blogspot.com/
O documento discute os conceitos fundamentais de Domain-Driven Design (DDD): (1) Ubiquitous Language é uma linguagem comum entre especialistas técnicos e de domínio; (2) Domain Model é um modelo conceitual do domínio que representa visões de negócio e técnicas; (3) Patterns são soluções para problemas recorrentes que ligam o Domain Model à implementação.
The document discusses Cisco VPN solutions, including an introduction to IPSec and IPSec VPN topologies. It provides information on Cisco site-to-site VPN solutions and the basics of initiating an IPSec session through phase one and two negotiations. It also briefly summarizes encrypting and decrypting packets, rebuilding security associations, and provides a simple IPSec configuration example.
[ 2018 컨테이너 기술의 모든 것 ] NBP 박기은 CTO 세션에서 소개된 네이버 클라우드 플랫폼의 컨테이너 기술 관련 서비스 및 향후 로드맵을 공유합니다.
[ 2018 All About Container ] Presentation about container technology & service roadmap of NAVER CLOUD PLATFORM by NBP cloud solution CTO "Park Ki Eun"
This document discusses the different layers and types of cloud computing as defined by NIST, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). IaaS provides on-demand provisioning of servers and infrastructure resources over the internet. PaaS provides development platforms and tools to build and run applications remotely without having to manage the underlying infrastructure. SaaS provides software applications that users can access over the internet through a web browser or mobile device without installing or maintaining the software.
In this presentation, we will explore the RESTApi as the ClearPass API integrations and further developments are more focused to RESTApi than the other existing API services like xml-rpc, SOAP, etc.Check out the webinar recording where this presentation was used: http://community.arubanetworks.com/t5/Security/Technical-Webinar-Getting-Started-with-the-ClearPass-REST-API/td-p/410214
Register for the upcoming webinars: https://community.arubanetworks.com/t5/Training-Certification-Career/EMEA-Airheads-Webinars-Jul-Dec-2017/td-p/271908
The document provides examples and explanations of network address translation (NAT) configurations on Palo Alto Networks next-generation firewalls. It shows how NAT policies work with security policies to translate source and destination IP addresses and apply firewall rules. The first example demonstrates static destination NAT to map any internal address to a single public address. The second example uses source NAT to map a DMZ subnet to an internal address. Flow charts illustrate how the firewall evaluates zones, NAT rules, security rules and applies address translations at each step.
An Architecture For Federated Cloud ComputingFiona Phillips
The document summarizes a model for federated cloud computing that allows cloud providers to share resources while maintaining independence. It proposes principles of federation, independence, isolation, elasticity, business orientation, and trust to address issues like scalability and lack of interoperability among current cloud providers. The model defines roles of service providers, infrastructure providers, and a reference architecture with components like the service manager and VEE manager to support automated provisioning and management of services across cloud providers.
For WLANs to be able to reliably support mission-critical, high-throughput, or time-sensitive applications, RF interference must be continuously monitored. The WLAN must automatically and dynamically adapt to mitigate the effects of any interference in the environment. WLAN infrastructure has to provide the administrators with real-time, historical, and proactive visibility into the air to diagnose and mitigate interference. In this application note we will look at some of the tools that Aruba offers as a part of its WLAN solution that enable administrators to ensure reliable, high performing RF.
To learn more, visit us at http://www.arubanetworks.com/wlan. Join the discussion at https://community.arubanetworks.com
This document summarizes the state of research in service-oriented computing. It discusses key concepts like service-oriented architecture (SOA) and how it promotes assembling application components into a loosely coupled network of services. The document outlines research challenges in areas like service foundations (discovery, binding etc.), composition, management/monitoring, and design/development. It provides examples of the current state of research on topics like enterprise service buses, self-managing services, and engineering service applications.
In this slides deck, we gonna look into Wireless penetration testing requirements like hardware & software, Various IEEE standards. and also deep dive into WEP, WPA, WPA2 & its Security threats & Security best practices.
This document discusses key concepts related to cloud adoption and cloud rudiments. For cloud adoption, it states that cloud is suitable for low priority or short term projects that have low availability requirements and short life spans. For cloud rudiments, it outlines essential cloud capabilities like resource aggregation, application services, self-service portals, and dynamic resource management. It also discusses concepts like reservation of services, allocation engines, reporting and accounting, and metering of resources.
ClearPass Insight is a software application that provides analytics, reporting, and compliance tools for network access information captured by the ClearPass Policy Manager. It generates customized reports on authentication records, audits, and network trends. ClearPass Insight includes predefined report templates and alerts that can be customized. It allows aggregation of data from multiple sources and generation of real-time and historical reports.
Palo Alto Networks SASE Deck. A SASE (secure access service edge) architecture combines networking and security as a service functions into a single cloud-delivered service at the network edge. In short, a SASE architecture identifies users and devices, enables secure access, delivers secure access to the appropriate applications, while providing network security from the cloud to protect users, applications, and data regardless of where they are. Combined with Prisma SD-WAN, Palo Alto Networks offers the industry's most complete SASE solution.
This document compares the Simple Network Management Protocol (SNMP) and Common Management Information Protocol (CMIP). SNMP is located in the application layer and is responsible for exchanging data between network devices using three mechanisms: managed devices, agents, and a network management system. CMIP was created by the Internet Activities Board for information exchange between management stations and agents using operations and protocol data units. While SNMP is better suited for local area networks, CMIP is more applicable to wide area networks due to supporting more objects and stronger security. Ultimately, the document argues that SNMP and CMIP should not be directly compared as they serve different purposes analogous to a high-level programming language versus assembly language.
SSL Checklist for Pentesters (BSides MCR 2014)Jerome Smith
This document provides a summary of checks that a pentester should perform when evaluating the security of SSL/TLS implementations. It discusses checking for support of outdated and insecure protocols like SSLv2 and SSLv3. It also recommends validating support for newer, more secure versions like TLSv1.1 and TLSv1.2. The document outlines steps to check for vulnerabilities like Heartbleed, BEAST, and CRIME. It also provides guidance on evaluating certificate validity, cipher suites, and renegotiation support. Web application considerations like mixed content and HTTP Strict Transport Security are also covered at a high level. The presenter provides these checks and recommendations from the perspective of a pentester to identify potential issues to consider reporting
Webinar presentation March 3, 2016.
The CSCC deliverable, Practical Guide to Hybrid Cloud Computing, contains prescriptive guidance for the successful deployment of hybrid cloud computing. The whitepaper outlines the key considerations that customers must take into account as they adopt hybrid cloud computing and covers the strategic and tactical activities for decision makers implementing hybrid cloud solutions as well as technical considerations for deployment.
Download the deliverable: http://www.cloud-council.org/resource-hub
Linux Yaz Kampı 2016 pfSense Firewall ve Router Eğitim Dökümanıİbrahim UÇAR
Bu eğitim dökümanı pfSense 2.2.6 kurulumu/yapılandırması, filtrelenmesi, dhcp, dns, vpn gibi temel servislerinin ne işe yaradıkları ve nasıl yapılandırılacağı gibi konuların işleneceği bir eğitimdir.
Serhad Makbuloğlu tarafından verilecek bu web seminerinde, Exchange Server 2010 Tips and Tricks anlatılacaktır. Bu web semineri teknik içeriğe sahiptir.
In this presentation, we will explore the RESTApi as the ClearPass API integrations and further developments are more focused to RESTApi than the other existing API services like xml-rpc, SOAP, etc.Check out the webinar recording where this presentation was used: http://community.arubanetworks.com/t5/Security/Technical-Webinar-Getting-Started-with-the-ClearPass-REST-API/td-p/410214
Register for the upcoming webinars: https://community.arubanetworks.com/t5/Training-Certification-Career/EMEA-Airheads-Webinars-Jul-Dec-2017/td-p/271908
The document provides examples and explanations of network address translation (NAT) configurations on Palo Alto Networks next-generation firewalls. It shows how NAT policies work with security policies to translate source and destination IP addresses and apply firewall rules. The first example demonstrates static destination NAT to map any internal address to a single public address. The second example uses source NAT to map a DMZ subnet to an internal address. Flow charts illustrate how the firewall evaluates zones, NAT rules, security rules and applies address translations at each step.
An Architecture For Federated Cloud ComputingFiona Phillips
The document summarizes a model for federated cloud computing that allows cloud providers to share resources while maintaining independence. It proposes principles of federation, independence, isolation, elasticity, business orientation, and trust to address issues like scalability and lack of interoperability among current cloud providers. The model defines roles of service providers, infrastructure providers, and a reference architecture with components like the service manager and VEE manager to support automated provisioning and management of services across cloud providers.
For WLANs to be able to reliably support mission-critical, high-throughput, or time-sensitive applications, RF interference must be continuously monitored. The WLAN must automatically and dynamically adapt to mitigate the effects of any interference in the environment. WLAN infrastructure has to provide the administrators with real-time, historical, and proactive visibility into the air to diagnose and mitigate interference. In this application note we will look at some of the tools that Aruba offers as a part of its WLAN solution that enable administrators to ensure reliable, high performing RF.
To learn more, visit us at http://www.arubanetworks.com/wlan. Join the discussion at https://community.arubanetworks.com
This document summarizes the state of research in service-oriented computing. It discusses key concepts like service-oriented architecture (SOA) and how it promotes assembling application components into a loosely coupled network of services. The document outlines research challenges in areas like service foundations (discovery, binding etc.), composition, management/monitoring, and design/development. It provides examples of the current state of research on topics like enterprise service buses, self-managing services, and engineering service applications.
In this slides deck, we gonna look into Wireless penetration testing requirements like hardware & software, Various IEEE standards. and also deep dive into WEP, WPA, WPA2 & its Security threats & Security best practices.
This document discusses key concepts related to cloud adoption and cloud rudiments. For cloud adoption, it states that cloud is suitable for low priority or short term projects that have low availability requirements and short life spans. For cloud rudiments, it outlines essential cloud capabilities like resource aggregation, application services, self-service portals, and dynamic resource management. It also discusses concepts like reservation of services, allocation engines, reporting and accounting, and metering of resources.
ClearPass Insight is a software application that provides analytics, reporting, and compliance tools for network access information captured by the ClearPass Policy Manager. It generates customized reports on authentication records, audits, and network trends. ClearPass Insight includes predefined report templates and alerts that can be customized. It allows aggregation of data from multiple sources and generation of real-time and historical reports.
Palo Alto Networks SASE Deck. A SASE (secure access service edge) architecture combines networking and security as a service functions into a single cloud-delivered service at the network edge. In short, a SASE architecture identifies users and devices, enables secure access, delivers secure access to the appropriate applications, while providing network security from the cloud to protect users, applications, and data regardless of where they are. Combined with Prisma SD-WAN, Palo Alto Networks offers the industry's most complete SASE solution.
This document compares the Simple Network Management Protocol (SNMP) and Common Management Information Protocol (CMIP). SNMP is located in the application layer and is responsible for exchanging data between network devices using three mechanisms: managed devices, agents, and a network management system. CMIP was created by the Internet Activities Board for information exchange between management stations and agents using operations and protocol data units. While SNMP is better suited for local area networks, CMIP is more applicable to wide area networks due to supporting more objects and stronger security. Ultimately, the document argues that SNMP and CMIP should not be directly compared as they serve different purposes analogous to a high-level programming language versus assembly language.
SSL Checklist for Pentesters (BSides MCR 2014)Jerome Smith
This document provides a summary of checks that a pentester should perform when evaluating the security of SSL/TLS implementations. It discusses checking for support of outdated and insecure protocols like SSLv2 and SSLv3. It also recommends validating support for newer, more secure versions like TLSv1.1 and TLSv1.2. The document outlines steps to check for vulnerabilities like Heartbleed, BEAST, and CRIME. It also provides guidance on evaluating certificate validity, cipher suites, and renegotiation support. Web application considerations like mixed content and HTTP Strict Transport Security are also covered at a high level. The presenter provides these checks and recommendations from the perspective of a pentester to identify potential issues to consider reporting
Webinar presentation March 3, 2016.
The CSCC deliverable, Practical Guide to Hybrid Cloud Computing, contains prescriptive guidance for the successful deployment of hybrid cloud computing. The whitepaper outlines the key considerations that customers must take into account as they adopt hybrid cloud computing and covers the strategic and tactical activities for decision makers implementing hybrid cloud solutions as well as technical considerations for deployment.
Download the deliverable: http://www.cloud-council.org/resource-hub
Linux Yaz Kampı 2016 pfSense Firewall ve Router Eğitim Dökümanıİbrahim UÇAR
Bu eğitim dökümanı pfSense 2.2.6 kurulumu/yapılandırması, filtrelenmesi, dhcp, dns, vpn gibi temel servislerinin ne işe yaradıkları ve nasıl yapılandırılacağı gibi konuların işleneceği bir eğitimdir.
Serhad Makbuloğlu tarafından verilecek bu web seminerinde, Exchange Server 2010 Tips and Tricks anlatılacaktır. Bu web semineri teknik içeriğe sahiptir.
Group Policy Logon Script ile Paylaşım Klasörü MaplemekMehmetKelepce
Windows server 2012 üzerinde Group Policy kullanılarak logon scripti ile ağ ortamındaki bir paylaşım klasörünün disk olarak maplenmesinin anlatıldığı makale
11.10.2017 tarihinde İstanbul Yıldız Teknik Üniversitesi Davutpaşa Kampüsü Teknoparkı A1 Blok'ta Ceph Türkiye adına yapılan ikinci meetup'a ait sunum. Dr. Hüseyin ÇOTUK tarafından yapılan sunum süresince aşağıdaki konular ele alınmıştır.
Ceph Yapıtaşları
Ceph Mimarisi
Ceph Üzerinde Veri Yerleşimi
CRUSH Algoritması
CRUSH Map
OpenStack Entegrasyonu
Pardus Kurulumu
PARDUS, Debian GNU/Linux [1] temelli açık kaynak kodlu bir işletim sistemidir. İnternet üzerinden ücretsiz olarak indirilebilmekte ve kolay kurulabilmektedir. Kişisel veya kurumsal kullanımlar için Pardus’un rekabet edebilir ve sürdürülebilir bir işletim sistemi haline getirilmesi için TÜBİTAK ULAKBİM bünyesinde geliştirme ve idame çalışmaları devam ettirilmektedir.
OSSEC (HIDS)
Veri merkezlerinde tüm sistemlerin loglarının izlenmesi ve olası anormallikleri tespit edip, müdahale edilebilmesi için proaktif bir sistem yönetiminin kurulması gerekmektedir. Böyle bir proaktif sistem kurulumu olarak NIDS (network-based intrusion detection ) ve HIDS (host-based intrusion detection) olmak üzere iki farklı yöntem bulunmaktadır. Bu makalede OSSEC (HIDS) yöntemi kullanarak log izleme (monitorig), dosya bütünlük kontrolü, rootkit tespiti özelliklerine değineceğiz.
2. İçindekiler
1. Cluster Yapısı & Türleri
a. Yüksek Erişilebilirlik (High Availability)
b. Yük Dağılımlı (Load Balancing)
c. Yüksek Performans (High Performance)
d. Cluster İçin Gerekli Temel Bilgiler
2. Node’ ların Kurulumu & Veri Depolama Bağlantısı
a. Network Power Switch Konfigürasyonu
b. SAN Anahtar Konfigürasyonu
c. Veri Depolama Ünitesi(Storage) Konfigürasyonu
d. Multipath Konfigürasyonu
e. Bonding / Teaming Konfigürasyonu
3. Cluster Konfigürasyonu İçin Sunucuların Hazırlanması
4. Cluster Konfigürasyonu &Yönetimi
a. Cluster Oluşturma(Create)
b. Quorum Disk Oluşturma (opsiyonel)
c. Data Diski Oluşturma
d. Resources
e. Failover Domains
f. Fence Devices
3. g. Services Groups
h. Cluster Konfigürasyon Dosyasını İnceleme
i. Grafik Arayüzden Varolan Cluster’a Node Ekleme-Kaldırma
5. Cluster Konfigürasyonu &Yönetimi (Komut Satırı)
a. Cluster Oluşturma(Create)
b. Cluster’a Node Ekleme/Kaldırma
c. Fence Devices
d. Failover Domains
e. Resources
f. Service Groups
6. Cluster Yedekleme & Geri dönüş (Backup & Restore)
a. Cluster konfigürasyon dosyasının yedeğini alma & geri dönüş
b. Luci(Grafik arayüz) konfigürasyon yedekleme & geri dönüş
7. Cluster Konfigürasyonunda Sorun Giderme
(Troubleshooting)
8. Kavramlar
9. Ekler
Ek-1: Linux Yöneticisi İçin Komutlar
Ek-2: MBR ve GPT disk türlerinin karşılaştırması
Ek-3: Default Multipath Konfigürasyon Seçenekleri
4.
5. BÖLÜM – 1
Cluster Yapısı & Türleri
Cluster kelime anlamı kümedir. Bilişim dünyasında birden fazla donanımın
aynı anda tek bir çatı altında bereber çalıştırıldığı teknolojidir. Amaç SPOF
(Single Point Of Failure) tek bir noktada oluşabilecek hatalara karşı önlemler
almaktır.
Bunlara örnek vermek gerekirse:
İşletim sisteminin çökmesi
Üzerinde çalışan uygulamanın kapanması
İstenmeyen ama yapılan servis kesintileri. Örneğin çekirdek
güncellemesi
Donanımsal kartlar, portlar ve kablo gibi vb. parçalarda olabilecek
arızalar
... vb
İş sürekliliği çözümleri, olası bir arıza veya felaket durumunda sistemlerin
kesintisiz bir şekilde çalışmasını sağlamaktır. Kesinti durumunda başınızı
ağrıtacak uygulamalarınıza önceden tedbir almakta diyebiliriz. Günümüzde
sistemleri incelediğimizde ise en yaygın olarak kullanılan iş sürekliliği çözümü
olarak, “Cluster” sistemler gelir. Cluster sistemler yapı olarak geniş bir kapsamda
farklı amaçlar için farklı çözümler sunabilmektedir. Bu çözümler arasından sıkça
kullanılan ve yüksek erişilebilirlik olarak adlandırılan cluster çözümü üzerinde
duracağız. Yapacağımız çalışmalarıda uygulamalı olarak gösteriyor olacağız.
Uygulama olarak cluster kurulumu sonrasında mysql veritabını’nımızı cluster
üzerinde yüksek erişilebilirlik (HA) şeklinde kullanmayı planlıyorum. Sizlerde
kendi istediğiniz uygulamalarınızı cluster sistemler üzerinde çalıştırabilirsiniz.
Kesintisiz bir iş sürekliliği çözümü olarak cluster sistemler önem arz etmektedir.
Cluster türleri genel olarak 3 grupta toplanır:
A. Yüksek Erişilebilirlik (High Availability): Bu yapıda amaç verilen
hizmetin kesintiye uğramamasıdır. Oluşturulan cluster yapısı ile bir ya da
6. birden fazla yedek sunucu çalışır ve hazır vaziyette bekletilip, aktif olarak
çalışan sunucu’nun kesintiye uğraması durumunda devreye girmesi
sağlanır. Böylece hizmet kesintiye uğramaz.
B. Yük Dengeleme (Load Balancing): Bu yapıda amaç yapılacak iş
yükünün cluster’daki sunucular arasında iş yoğunluğu gözetilerek yük
dağılımının yapılmasıdır. Bundan dolayı tüm sunucular aktif durumdadır.
Clusterdaki sunuculardan birinin kesintiye uğraması durumunda iş yükü,
clusterda kalan sunucular arasında dağıtılır.
C. Yüksek Performans Hesaplama (High Performance Computing):
Yüksek performans hesaplama işlerinde kullanılan cluster yapısıdır.
Yapılacak iş parçalara bölünerek sunuculara gönderilir ve sunuculardan
gelen sonuçlar tekrar birleştirilerek iş tamamlanır. Yük dengeleme cluster
modelinde her bir sunucuya bir iş verilmesi söz konusuyken; bu yapıda
tek bir işin parçalara bölünerek her bir sunucuya gönderilmesi ve
sunuculardan gelen sonuçların birleştirilmesiyle yapılan tek bir iş söz
konusudur. Bu cluster yapısı genel olarak bilimsel hesaplama ve
araştırmaların yapıldığı yerlerde kullanılır.
D. Cluster İçin Gerekli Temel Bilgiler
Linux, cluster mimarisinde yüksek erişilebilirlik(HA) oluşturmak istediğimiz
kaynakları, konfigürasyon sırasında bize sunmaktadır.(Örn: Apache, Mysql,
Oracle, NFS vb.) Linux’un bize sunduğu bu uygulamaların dışındaki uygulamaları
da kendi yazacağımız scritplerle yüksek erişilebilirlik(HA) çözümleri
oluşturabiliriz. Cluster sistemlerin kurulum-konfigürasyonunda yedekli bir yapının
oluşturulması(bonding,multipath,donanımsal vb.) ve sistemin kesintisiz
çalışmasını sağlayacak çalışmaların tamamını kapsayacak şekilde bir çalışma
yapılmıştır. Veri disklerinin oluşturulmasında dikkat edilmesi gereken GPT ve
MBR formatlı disk yapılarından, cluster mimarisinin yedekleme-geri
dönüş(backup-recovery) konularına kadar baştan sona cluster yapılandırmasını
gerektiren bilgilerden bahsedilmiştir. Son olarakta oluşturulan Cluster
Konfigürasyonunda Sorun Giderme(Troubleshooting) ile ilgili temel
karşılaşılabilecek sorunlardan ve yöntemlerden bahsedilmiştir.
7. Yapılan çalışma gerekli bütün komutları ve sistemi kurmak için görsellik
açısından çıktılarını içermektedir.
Genel olarak aşağıdaki konular üzerinde durulmuştur.
Linux cluster çözümleri
Node’ların kurulumu ve Veri depolama bağlantısı
Multipath konfigürasyonu
Bonding / Teaming konfigürasyonu
Ext4 ve gfs2 dosya sistemlerine bakış
MBR ve GPT formatlı disk oluşturma işlemleri (parted komutu)
Linux cluster yedekleme ve geri dönüş(backup-recovery)
Cluster Konfigürasyonunda Sorun Giderme (Troubleshooting)
Cluster sistemler kritik uygulamalar için güvenirlilik, ölçeklenebilirlik ve
ulaşılabilirlik sağlar. Bir failover(belirli bir donanım parçasının çökmesinden
sonra ağa erişimin kesintiye uğramamasını sağlamak için kullanılan fazlalık)
yapıda cluster kurmak için temel adımları aşağıdaki gibi sıralayabiliriz;
a. Donanım gereksinimleri ve kurulumlarının yapılması
i. Linux işletim sisteminin kurulumunun yapılacağı
sunucuların belirlenmesi (en az 1GB RAM)
ii. Ağ anahtarı(Network Switch), cluster’a erişim için gerekli
iii. Akıllı PDU(Network power switch), kurumsal seviyede
bir clusterda fencing gerçekleştirmek için gerekli
iv. SAN anahtar(fiber anahtar), fiber kanallı veri depolama
ünitesine erişim için gerekli, diğer bir seçenek ISCSI’ dir.
(Opsiyonel) SAN anahtarınız olmasada sunucularınızı,
veri depolama ünitesine direk bağlayabilirsiniz.
v. Veri depolama ünitesi(Storage), disk paylaşımını
yapacağımız, SAN mimaride bir veri depolama ünitesidir.
b. High Availability yazılımlarının kurulması
Kurulumu iki yöntemle yapabilirsiniz;
vi. Linux işletim sistemleri kurulumunu yaparken cluster için
gerekli paketlerin kurulumunu yapabilirsiniz.
8. vii. Grafik arayüzden(Conga), cluster için gerekli yazılımları
kurabilirsiniz.
c. Cluster konfigürayonlarının yapılması
Konfigürasyonları üç ayrı yöntemle yapabilirsiniz;
viii. Grafik arayüz(Conga), cluster konfigürasyonlarını
yapabileceğiniz ve yönetebileceğiniz kullanıcı arayüzüdür.
ix. ccs komutu ile, cluster konfigürasyonlarını yapabilir ve
yönetebilirsiniz.
x. Doğrudan temel bir cluster.conf dosyası belirleyerek,
üzerinde istediğiniz çalışmaları yapabilirsiniz.
Not: Cluster kurulumunu RedHat Enterprise Linux işletim sistemleri üzerine
kuruyor olacağız. Sizlerde isterseniz CentOS, Oracle Enterprise Linux vb. işletim
sistemlerine kurabilirsiniz.
N ot : RedHat Enterprise Linux işletim sistemleri dökümanlarının tamanına
aşağıdaki belirtilen linkten ulaşabilirsiniz.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/
Not: CentOS ve Oracle Enterprise Linux işletim sistemlerini ücretsiz olarak
indirebilirsiniz.
Not: Conga cluster yönetimi için kullanılabilecek grafik arayüzdür.
Not: Cluster Sunucu(node) sayısı High Availability ile en fazla 16 dır.
Not: Linux cluster ile ilk defa uğraşanlar fence aygıtının ne olduğunu sorabilirler.
Fence aygıtı veri bütünlüğü için, sadece bir node üzerinde çalışan cluster
servislerinin herhangi bir sorun durumunda diğer node üzerine geçişini sağlayan
ve kesintisizliği sağlamak adına veri bütünlüğünü garanti etmek için kullanılır.
N ot : Redhat Enterprise Linux Cluster için fence aygıtlarından hangisinin
kullanılacağını yada kullanıldığının bilgisi ve uygunluğu
http://www.redhat.com/cluster_suite/hardware/ bu link üzerinden kontrol
edilmelidir. Fence device seçiminde önerilen network power switch veya SAN
anahtar kullanılmasıdır.
9.
10. BÖLÜM – 2
Node’ ların Kurulumu & Veri Depolama Bağlantısı
Öncelikle kurucağımız sistemin no-single-point-of-failure(tek bir noktadan
olabilecek hataya karşı sistemin çalışmasını sağlamak) olması için cluster
sistemin aşağıda belirtildiği gibi yedekli bir yapıda oluşturulması gereklidir.
Veri depolama ünitesi çift denetçili(dual-controller) olmalıdır.
Ağ portları yedekli bir şekilde yapılandırılmalıdır. (bonding)
Sunucu ve veri depolama arasındaki bağlantılar(fiber yada iscsi)
yedekli bir şekilde yapılmalıdır.
Sunucu üzerindeki işletim sistemlerini kuracağımız diskler korumalı
bir şekilde yapılandırılmalıdır. (Raid 1,3,5,6 konfigürasyonları)
Veri diskini oluşturacağımız veri depolama ünitesi üzerindeki diskler
korumalı bir şekilde yapılandırılmalıdır. (Raid 1,3,5,6
konfigürasyonları yada disk pool mantığı)
Sunucu ve veri depolama ünitesi güç kabloları yedekli bir şekilde
bağlantıları yapılmalıdır.
SAN anahtar varsa, yedekli bir şekilde yapılandırılmalıdır.
Fence Device olarak Akıllı PDU (Network power switch)
kullanıyorsanız yedekli olması için 2 adet olmalıdır.
Burada belirttiğimiz yedekli yapının, cluster kurmak için zorunlu olduğu
anlamına gelmemelidir. Sadece yapılacak sistemin kapsamlı bir şekilde
yedekliliğinin sağlanmasıyla kesintisiz bir iş sürekliliği çözümü olması
düşünülmüştür.
İlk olarak iki adet sunucu üzerine Linux işletim sistemleri kurulumlarını
gerçekleştiriyoruz. Kurulumu yaparken cluster için gerekli bir çok paket
bulunmaktadır bunlarla sonradan uğraşmamak için, kurulum sırasından “High
Availability” seçeneğini işaretlemek gerekiyor. Bunun dışında kurulacak Linux
işletim sistemini özelleştirebilir istediğiniz paketleri kurarak istemediklerinizi
çıkartabilirsiniz. Ben gerektiğinde desktop arayüzünü kullanmak için “Desktop”
seçeneğini seçiyorum, sonrasında “High Availability” seçeneğinide işaretledikten
sonra, cluster olarak çalıştıracağım “mysql” paketlerini de ekleyerek işletim
11. sistemleri kurulumlarını gerçekleştiriyorum.
Not: Cluster yapıda “node” olarak tabir ettiğimiz aslında bizim cluster için
kullandığımız sunucularımızdır. Bundan sonraki cluster ile ilgili yerlerdeki
ifadelerde “sunucu” yerine “node” ifadesini görebilirsiniz.
Node’ların kurulumunu kısaca aşağıdaki gibi sıralayabiliriz;
a. Sunucu disklerini Raid1 yapıyoruz.
b. Linux işletim sistemi kurulacak ve kurulum içerisinde boot dizin ile
beraber;
i. / dizini 50GB
ii. Swap 16GB
iii. /test dizini geri kalan tüm kapasite
c. “ip” adreslerinin belirlenmesi ve verilmesi
d. “Desktop” seçeneğinin işaretlenmesi
e. “High Availability” seçeneğinin işaretlenmesi
f. “Mysql” paketlerinin eklenmesi
Buradaki amaç cluster kurumları olduğu için, ayrıntılı olarak cluster
konfigürasyonlarına ve yönetimine değineceğiz. Bundan dolayı işletim sistemleri
gibi kurulumların ayrıntılarına girmiyoruz.
Not: Eğer subscription ve support alarak RedHat Enterprise Linux 6 ile Cluster
Kurulumlarını gerçekleştirmek istiyorsanız RedHat işletim sistemi ile beraber
gerekli Add-On ‘lar:
High Availability : Redhat Cluster kurabilmek için gereklidir.
Resilient Storage : GFS Clustered dosya sistemi (File System) için gereklidir.
Burada Resilient Storage Add-On , High Availability Add-On‘u da içermektedir.
Sadece Resilient Storage Add-On alınarak GFS2 dosya sistemli (File System) bir
RedHat Cluster kurabilirsiniz. Eğer Cluster ortamınızda GFS2 olmayacaksa
sadece High Availability alınması yeterli olacaktır.
Not: RedHat Enterprise Linux 6 tek bir sunucu üzerinde dosya sistemi (File
System) olarak GFS2 desteklemez.
Not: GFS2 dosya sistemi (File System) oluşturulduktan sonra, dosya sisteminin
12. boyutunu azaltamazsınız ancak oluşturmuş olduğunuz dosya sisteminin boyutunu
“gfs2_grow” komutuyla arttırabilirsiniz.
Not: Linux işletim sistemleri kurulumlarını, sanallaştırma sistemleri üzerinde
yapıyorsanız, sanallaştırmanın clone’lama özelliğini kullanılarak ikinci
makinenizi clone’lama mantığı ile kısa bir sürede gerçekleştirebilirsiniz. Fakat
burada dikkat etmeniz gereken nokta iki makinenin de isminin aynı olmasıdır.
Clone’lama bittikten sonra ikinci makinenizin hostname’ini aşağıdaki gibi
değiştirmeniz gerekmektedir.
Örneğin birinci makinemize node1 ismini vermiştik. Şimdi ikinci
makinemizin hostnameni node2 yapacağız. Clone’ladığımız makineye
bağlanıyoruz ve aşağıdaki komutlarla hostname’ini node2 olarak değiştiriyoruz;
# vi /etc/sysconfig/network
# reboot
Bu sistemler 2 adet Rhel6_Node1 & Rhel6_Node2olarak aşağıdaki şekil
2.1’deki gibi görülmektedir. Sunuculara veri depolama ünitesi (storage) üzerinden
cluster’ın kullanacağı ortak alan diyeceğimiz bir alan verip, her iki linux sunucu
üzerinden “fdisk -l” komutuyla ortak olanı görüp görmediğinizi kontrol
edebilirsiniz. Ortak alan olarak verilen diskleri görmüyorsanız dert etmeyin
okumaya devam edin.
Şekil 2.1 Sanallaştırma üzerinde örnek uygulama olarak kurduğum cluster
node’ları
Biz sistemimizi fiziksel yapı üzerinde kuracağımız için sanallaştırma ile ilgili
gerekli bilgileri kısaca vermiş bulunuyoruz.
13. Öncelikle kuracağımız sistemdeki gerekli cihazları belirtelim;
2 adet Sunucu # Linux cluster için 16’ya kadar çıkabilir
1 adet Veri Depolama ünitesi (dual controller)
1 adet SAN anahtar (opsiyonel)
2 adet Network power switch(Akıllı PDU) (Cluster failover yapısı
için gereklidir.)
2 adet ağ anahtarı (iç ağ ve dış ağ) # bir tane olmasıda
yeterlidir.
Ve gerekli güç, ağ, fiber kablolar..
Kuracağımız yapıyı aşağıdaki şekil 2.2’deki gibi resmedebiliriz.
Şekil 2.2 Kuracağımız sistemin fiziksel yapısının gösterimi
Fiziksel olarak kurulumu gerçekleştirmek için gerekli adımlar;
Sunucuları fiber kablolar ile SAN anahtar üzerinden yada SAN
anahtarımız yoksa doğrudan yedekli olarak veri depolama ünitesine
bağlıyoruz. Yukardaki şekilde görüldüğü üzere, biz doğrudan
14. bağlantıları gerçekleştirdik.
Sunucuların ağ(network) yedekliliği (bonding) için2 adet ağ
portunu iç ağ anahtarına bağlıyoruz. Yukardaki şekilde görüldüğü
üzere iç ağ ve dış ağ yapılarınız varsa herbir sunucuyu dış ağ’a da
bağlamalısnız.
Sunucuların varsa yönetim portlarınıda ağ anahtarına bağlayıp ip
adreslerini veriyoruz. Herhangi bir sıkıntıda uzaktan sunucularımıza
bağlanıp işlemlerimizi yapabilmek için gereklidir. Yukardaki
şekilde karışıklığa yol açmaması için gösterilmemiştir.
Sunucularıngüç kablolarını (power) network power switch’imize
bağlıyoruz. Eğer network power switch olarak adlandırılan akıllı
PDU üzerinde yer yoksa, veri depolama ünitesinin güç kablosunu
normal bir enerji hattınada bağlayabilirsiniz. Fence device için
önemli olan sunucuların güç kablolarının network power switch
üzerine bağlanmasıdır.
Network power switch ve veri depolama ünitesininde yönetimini
sağlamak için, iç ağ anahtarına bağlantılarını gerçekleştiriyoruz.
A. Network Power Switch Konfigürasyonu
Fence device tercihimizi yaparken, Bölüm-1’de belirttiğimiz link üzerinden
baktığımızda, fence device olarak kullanılabilecek aygıtları görebiliriz. Genel
olarak fence device olarak network power switch kullanımı tavsiye edildiğinden
bizde verilen link üzerinden belirtilen, apc network power switch kullanımını
tercih ediyoruz.
Apc network power switch konfigürasyonu için, console üzerinden network
power switch’e bağlanıp ağ yapısından statik bir ip adres verilmesi yeterlidir.
Console dan bağlanınca default kullanıcı: “apc” ve şifre: “apc” girdikten sonra
network ayarlarına girip statik ip verme işlemini gerçekleştiriyorsunuz. Belirli bir
ip adres verildikten sonra eğer gerekirse apc network power switch grafik
arayüzüne http://ip_adress bağlanıp istediğiniz ayarları yapabilirsiniz.
B. SAN Anahtar Konfigürasyonu;
Sisteminizde SAN anahtar(switch) varsa; SAN anahtarlar default olarak
15. üzerlerinde zone konfigürasyonları olmadan gelirler ve SAN anahtarı
çalıştırdığınız andan itibaren üzerinden geçen tüm fiber trafiğine izin verirler.
SAN anahtarların bu şekilde kullanılması önerilmemektedir. Çünkü SAN
anahtarlar bu şekilde zone konfigürasyonları yapılmadan kullanıldığında
performans problemlerine yol açabilirler. SAN anahtar üzerindeki bir initiator
tarafından gönderilen scsi bus reset komutu switch üzerinde ki diğer tüm initiator
ve target tarafından alınacağı için fiber oturumlar sonlanarak tekrar başlamak
zorunda kalabilir. SAN yapınızda problemli bir HBA(Host Bus Adapter)
bulunması durumunda size beklenmedik problemler çıkartabilir. Bu tarz
problemlere geçit vermemek için mutlaka SAN anahtar üzerinde zone
konfigürasyonu yapılmasını tavsiye ediyoruz.
Zone konfigürasyonu iki farklı şekilde yapılabilir;
Software zoning: software zone yaptığında fiziksel olarak hangi port’a hangi
kabloyu taktığın önemli değildir.
Hardware zoning: hardware zone yaparsan, SAN anahtar üzerindeki herbir port
üzerinden zone yaptığın için, SAN anahtar üzerinde hangi porta nereden gelen
fiber kabloyu taktığını bilmelisin. Aksi takdirde yanlış kablolamada sistem
çalışmaz.
SAN anahtar konfigürasyonu üç aşamada gerçekleştirilir;
Alias oluşturma
Zone oluşturma
Yapılan konfigürasyonların kaydedilmesi
Not: Zoning yaparken dikkat edilmesi gereken nokta, her bir zone içerisinde
sadece 1 adet initiator ve bu initiator tarafından kullanılacak bütün target’lar
girilmelidir. Yani her bir sunucudaki her bir HBA portu için zoning yapılması
önerilir.
SAN anahtar üzerinde yapılacak konfigürasyonları hemhttp://ip_adress üzerinden
bağlanıp grafik arayüzden hemde komut satırından yapabilirsiniz.
Aşağıda Brocade SAN anahtar üzerinde zoning işlemini yapabilmek için gerekli
16. komutları ve örnekleri bulabilirsiniz.
# switchshow # portları ve bu portlara bağlı wwn’leri gösterir.
# alishow # mevcut alias’ları gösterir.
# alicreate “node1_hba1”, “xx:xx:xx:xx:xx:xx:xx:xx” #wwn’lere alias
atama işlemi
# nodefind “xx:xx:xx:xx:xx:xx:xx:xx” #ilgili wwn’a ait yapılan
tanımlamaları görebiliriz.
# zonecreate “ZN_node1_hba1_ControllerA_ControllerB”,
“node1_hba1;ControllerA_1; ControllerB_1” # zone oluşturma işlemi, ZN_
ile başlayan kısım zone’a verdiğimiz isimdir. İkinci kısım ise bu zone içerisinde
bulunması gereken alias’lardır.
# cfgsave # Yapılan işlemleri kaydediyoruz.
# cfgcreate “LAB1_2601214”, “ZN_node1_hba1_ControllerA_ControllerB”
# SAN anahtar üzerinde aktif bir konfigürasyon yoksa, yaptığımız konfigürasyonu
SAN anahtar üzerinde oluşturma işlemi, LAB1_26012014 çalışacak olan
konfigürasyonun ismi, ZN_ ile başlayan ise içerisine dahil ettiğimiz zone ismidir.
# cfgadd “LAB1_2601214”, “ZN_node1_hba1_ControllerA_ControllerB” #
SAN anahtar üzerinde aktif bir konfigürasyon varsa, yeni oluşturduğumuz zone’u
konfigürasyona ekleme işlemi
# cfgenable “LAB1_2601214” # LAB1_26012014 olarak yeni
oluşturduğumuz yada değişiklik yaptığımız konfigürasyon üzerinde yapılan
işlemlerin aktif olmasını sağlayan komut
Yukardaki komutlarla nasıl SAN anahtar üzerinde konfigürasyon yapıldığını
anlattık. Sizlerde bu şekilde konfigürasyonlarınızı yapabilirsiniz. Bunun dışında
SAN anahtarla ilgili aşağıda kullanışlı birkaç komut daha verdikten sonra SAN
konfigürasyon bölümünü tamamlıyoruz.
# cfgshow # SAN anahtar üzerindeki konfigürasyonları gösterir.
17. # switchname # SAN anahtara isim verilmesini sağlar.
# ipaddrset # SAN anahtara ip verilmesi sağlar.
# ipaddrshow # ip adresi görüntüleme yi sağlar.
# date # tarih bilgilerini güncelemeyi sağlar.
# sysshutdown # SAN anahtarı güvenli bir şekilde kapatmayı sağlar.
C. Veri Depolama Ünitesi(Storage) Konfigürasyonu;
Veri depolama ünitesi yönetim arayüzüne bağlanıyoruz;
Cluster için 10GB’lık veri (data) lun oluşturuyoruz.
Cluster host grubu oluşturuyoruz.
Host grubun içerisine cluster yapacağımız node’ları dahil ediyoruz.
Cluster host grubuna 10GB’lık lun’u map ediyoruz.
Not: Veri depolama ünitesi tarafında yapılacakları her üretici firmanın yönetim
arayüzü farklı çalışabileceği için, yapılacak işlemleri mantık olarak anlatıp
geçmiş bulunuyoruz.
Linux cluster host grubu olarak oluşturduğumuz node1 ve node2 host grubuna
10GB data lun’u map ettiğimize göre. Node’lar yeniden başlatıldığında 10GB’lı
data lun’u “fdisk –l” komutu ile node’lar üzerinde görebilir olacağız.
Peki sunucularımızı yeniden başlatmak istemesek… Ne Yapabiliriz?
Sunucuları Yeniden Başlatmadan (Reboot) Lun Tanıtma İşlemi
a. Cluster sunucularına veri depolama ünitesi üzerinden 10GB lun
vermiştik.
b. Sunucular üzerinden “fdisk –l” komutunu çalıştırdığımda herhangi bir
şey gözükmüyor.
c. Veri depolama ünitesi üzerinden verdiğim lun’u sunucuları yeniden
başlatmadan görebilmek adına aşağıdaki komutu çalıştırabilirsiniz.
host0 dan başlayarak ne kadar host varsa çalıştırmak gerekiyor.
# echo "- - -" > /sys/class/scsi_host/host0/scan
18. Şekil 2.3 Hostları taramak için echo komutunun kullanımı
d. Şimdi tekrar “fdisk –l” komutunu çalıştırdığımda 10GB verdiğim
lun’u aşağıdaki şekil 2.4’deki gibi görüyoruz.
Şekil 2.4 “fdisk –l” komutunun çıktısının bir kısmı
Not: Şekil 2.4’te görüldüğü üzere diskimizi yedekli bağladığımız için 2 yoldan
gözükmektedir. Bundan dolayı multipath driverlerın yüklenmesi ve tanımlanması
gerekmektedir. Eğer tek yoldan bağlantı yaptıysanız multipath driverlarını
yüklemenize gerek yoktur.
e. Cluster’a dahil olacak bütün node’lar üzerinde disk tanıtma işlemlerini
bu şekilde yapılması gerekmektedir.
Not: Sistemde oluşan herhangi bir karışıklıktan dolayı hala diskinizi
göremiyorsanız. Aşağıdaki komutta belirtildiği gibi “disk_isimlerini” taratıp
19. “fdisk –l” komutu ile kontrol ettiğinizde diskinizi görüyor olacaksınız.
# echo "- - -" > /sys/class/scsi_disk/”disk_isimlerini”/device/rescan
Not: Node’ları yeniden başlatmadan (reboot) diskimizi tanıtma işlemindeki "- - -"
ne anlama geldiği şuan aklınıza gelmiş olabilir.
Cevabını merak ediyorsanız okumaya devam edin…
Buradaki üç çizgi channel, SCSI target ID ve LUN anlamına gelmektedir.
Bunlar üzerinden sistemdeki herşeyi tarama işlemi yapılıyor.
D. Multipath Konfigürasyonu
Failover mimaride bir sistem kurduğumuz için cluster’daki sunucularımız,
veri depolama ünitesinden verilen disk alanını birden fazla yoldan görecektir.
Bundan dolayı multipath ayarlarının sunucularımız üzerinde yapılması
gerekmektedir.
Peki neden gereklidir ?
Multipath konfigürasyonu olmadan aynı disk alanını işaret eden iki farklı
aygıt dosyasını kullanarak bir okuma ya da yazma işlemi yaptığımızda verilerin
sağlamlığı tehlikeye atılmış olur. Multipath bunun gibi geçersiz okuma ve yazma
mekanizmasını devre dışı bırakarak, verilerin sağlıklı ve güvenli bir şekilde
tutulmasını mümkün kılar. Bunu sağlamak için her bir multipath aygıtın sahip
olduğu değişmeyen, benzersiz bir kimlik kullanır ki buna WWID (World Wide
Identifier) denir. WWID sistemden sisteme değişen değerlerden (sda, sdb gibi)
tamamen farklı olarak her durumda ve her bilgisayarda aynı paylaşım için aynı
değeri verir. Ön tanımlı olarak bir multipath aygıt bu ismi kullanır. Ancak
kullanıcılara kendilerinin oluşturacağı başka isimleri de kullanabilme hakkı veren
user_friendly_names seçeneği de mevcuttur. Multipath aygıtlarınızın kalıcı bir
şekilde sistemde bağlı kalmasını sağlamak için user_friendly_names özellğinin
devre dışı bırakılması önerilir. User_friendly_names özelliği devre dışı iken her
hangi bir bilgisayarda oluşturulacak multipath, default olarak aygıtın WWID
değerini kullanacağı için her bilgisayarda aynı multipath aynı isme/değere sahip
olacaktır.
20. Şekil 2.5 Multipath konfigürasyonun gerekliliği
DM-Multipath (Device-Mapper Multipath) aşağıdaki özellikleri sağlaması
için kullanılabilir;
Redundacy (Fazlalık)
DM-Multipath aktif-pasif konfigürasyonda failover sağlar yani herhangi bir
I/O yollarından (kablo, anahtar yada kontroller) birinde sorun olduğunda,
DM-Multipath diğer alternatif yollardan birini kullanır.
Improved Performance (geliştirilmiş performans)
DM-Multipath aktif-aktif olacak şekilde konfigürasyonu yapılabilir. Bu
durumda I/O için herhangi bir zamanda yolları beraber kullanarak
performans sağlar.
DM-Multipath komponentleri;
21. Tablo 2.1 DM-Multipath Komponentleri
DM- Multipath kurulum ve konfigürasyonu:
Yeni bir aygıt multipath tarafından algılandığında onu “/dev/..” dizini altında iki
ayrı yerde görebilirsiniz:
“/dev/mapper” altında bulunan aygıtlar boot işleminden hemen
sonra sistemde oluşturulan aygıtlardır. Bu aygıtları multipath
aygıtlara erişirken kullanacağız.
“/dev/dm-n” altında bulunan herhangi bir aygıtı kullanmanız
önerilmez. Bu aygıtlar sistem tarafından dahili kullanım içindir.
Node1 ve node2 makinelerimizi failover şeklinde veri depolama ünitesine fiber
ile bağlamıştık şimdi aşağıdaki şekillerdeki gibi wwn numaralarını görebiliriz.
Şekil 2.6 Node1 üzerinde wwn numaralarını gösteren komut ve çıktısı
Şekil 2.7 Node2 üzerinde wwn numaralarını gösteren komut ve çıktısı
Adım 1:
Device-mapper-multipath rpm paketini aşağıda verildiği gibi yüklüyoruz.
Bu paketleri cluster’a dahil edeceğimiz node1 ve node2 makinelerinin her
22. ikisinede yükledikten sonra adım adım aşağıda anlatıldığı gibi cluster’daki bütün
node’lar üzerinde multipath konfigürasyonunu yapıyoruz.
# rpm -ivh device-mapper-multipath-libs-0.4.9-72.el6.x86_64.rpm
# rpm -ivh device-mapper-multipath-0.4.9-72.el6.x86_64.rpm
Şekil 2.8 multipath paketlerini yüklemek için çalıştırılan komutların çıktısı
Adım 2:
Eğer /etc/multipath.conf dosyasını düzenlemek için bir sebebin yoksa default
DM-Multipath ayarlarını kullanmak failover için yeterli olacaktır. Bizde default
ayarları kullanacağız.
# mpathconf --enable --with_multipathd y
Şekil 2.9 mpathconf komutunun çalıştırılması
# chkconfig --list multipathd
Şekil 2.10 multipath komutunun her durumda çalışırlılığının kontrol edilmesi
Adım 3:
Multipath servisini user_friendly_names seçeneğini devre dışı bırakarak
23. başlatalım.
# mpathconf --enable --user_friendly_names n --with_multipathd y
# mpathconf
Şekil 2.11 mpathconf komutu ile multipath ayarlarının gösterimi
Adım 4:
Multipath servisini başlatıyoruz
# service multipathd start
Şekil 2.12 multipath servisinin başlatılması
# multipath -ll
Şimdi sistemimizin bağlı olduğu iki blok aygıtı (/dev/sdb ve /dev/sdc) aynı
kaynak olarak görüp görmediğine bakalım: aşağıda görüldüğü gibi herbir aygıt
artık tek bir kaynak olarak gözüküyor.
Şekil 2.13 multipath çalışırlılığının kontrolü
Yukarda şekilde görüldüğü gibi yolların durumu ready yada ghost ise multipath
çalışıyordur. Eğer yollar faulty yada shaky olarak gözüküyorsa multipath
çalışmıyordur.
24. Online_satus için olası değerler running ve offline dır. Eğer offline gözüküyorsa
SCSI device disable olmuş durumdadır.
Sistemimiz olması gerektiği gibi iki blok aygıtı tek bir aygıt olarak algılamış.
Yukarıdaki şekil 2.13’de görüldüğü üzere WWID değeri
(3600axxxxxxxxxxxxxxxxxxxxxx), sunucunun kendini tanıtmak için gönderdiği
string, paylaşım tipi, kapasite ve yazma politikası (wp=rw) görülüyor.
Adım 5:
Aygıtımız artık /dev/mapper altında WWID numarası ile görünecektir:
# ls -l /dev/mapper
3600axxxxxxxxxxxxxxxxxxxxx
Fakat mount işlemlerinde WWID yerine, bir alias tanımlayarak kullanmak
isterseniz multipath konfigürasyon dosyasında aşağıda belirtildiği gibi alias
tanımlaması yapılmalıdır;
# vi /etc/multipath.conf
multipaths {
multipath {
alias cluster_disk
wwid 3600axxxxxxxxxxxxxxxxxxxxx
}
}
# service multipathd restart
Artık ortak disk alanımız “/dev/mapper” altında cluster_disk ismiyle
görülecektir.
Adım 6:
“/etc/fstab” dosyasına gerekli kaydı girerek, her boot işleminde fiber diskimizin
otomatik olarak sisteme bağlanmasını(mount) sağlayabilirsiniz. Ancak biz cluster
mimaride çalışacağımız için fstab’a eklemiyoruz. Çünkü cluster node’lardan aktif
olan node diski üzerine alacaktır.
Aşağıdaki komutları çalıştırarak kullanılan üretici, kart ve aygıt bilgilerini
25. görebilirsiniz.
Şekil 2.14 Device Bilgilerinin Gösterimi
Not: Aşağıda verilen komut bizlere linux işletim sistemi içerisinden üretici bazlı
default multipath konfigürasyonları verir. Sisteminizde kullandığınız üretici
ürünlerine göre, gerekli görüldüğü takdirde multipath konfigürasyonunu
düzenleyebilirsiniz.
#cat /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf.defaults
Bu komutun çıktısını EK-1 de bulabilirsiniz.
E. Bonding / Teaming Konfigürasyonu
İş sürekliliği için sistemimizi cluster mimaride kurduğumuz gibi yedekli bir
yapı oluşturduğumuzdan dolayı, ağ (network) portları tarafında da yedeklilik
adına aşağıdaki şekil 2.15’de görüldüğü gibi bonding konfigürasyonunu
gerçekleştirebilirsiniz.
Şekil 2.15 ağ (network) port yedekliliğinin gösterimi
Aşağıdaki şekilde görüldüğü gibi eth0 ve eth1 arasında bond0 adında bir bonding
işlemi yapacağız.
26. Şekil 2.16 ifconfig komutuyla network portlarının gösterimi
Adım 1:
#vi /etc/modprobe.conf # komutuyla konfigürasyon dosyası oluşturarak
bonding işlemi için alias tanımlıyoruz. “alias bond0 bonding” yazıp,
kaydediyoruz.
Şekil 2.17 vi komutuyla alias tanımlama
#vi /etc/modprobe.d/bonding.conf # komutuyla bonding.conf adında bir
dosya oluşturup içerisine “alias bond0 bonding” yazıp kaydediyoruz.
Şekil 2.18 cat komutuyla alias’ın gösterimi
Adım 2:
Şimdi “/etc/sysconfig/network-scripts/” directory altında ifcfg-bond0 adında bir
dosya oluşturup aşağıdaki şekil 2.19’da görüldüğü gibi bonding interface
konfigürasyon dosyasını oluşturuyoruz.
Şekil 2.19 bonding interface konfigürasyonun gösterimi
27. Adım 3:
Şimdi de “/etc/sysconfig/network-scripts/” altında ifcfg-eth0 ve ifcfg-eth1
network portlarının dosyalarını aşağıdaki şekil 2.20’deki gibi düzenliyoruz.
Not: Bu işlemleri yaparken eth dosyalarını kopyalamayınız. Çünkü MAC ve
DEVICE adları herbir interface için farklıdır.
Şekil 2.20 network portlarının bonding konfigürasyonu için düzenlenmesi ve
gösterimi
Adım 4:
Konfigürasyoları yüklemek için network servislerini restart ediyoruz.
# service network restart # Komutu çalıştırdığımızda aşağıdakine benzer
çıktı almalıyız.
Shutting down interface eth0: Device state: 3 (disconnected) [ OK ]
Shutting down interface eth1: Device state: 3 (disconnected) [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface bond0: Active connection state: activated
Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/15
[ OK ]
Bringing up interface eth3: Active connection state: activated
Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/16
[ OK ]
28. Adım 5:
Aşağıdaki şekilde kontrol amaçlı bond0 network interface’in ip adresini
alıp almadığını kontrol ediyoruz. Ayrıca eth0 ve eth1 portlarının “SLAVE”
olduğunu ve bond0 network interface’in “MASTER” olduğunu görebiliriz. Bir
diğer dikkatinizi çekeceğim nokta MAC adreslerinin aynı olduğu durumdur.
# ifconfig -a
Şekil 2.21 ifconfig komutuyla son durumun gösterimi
Adım 6:
Bonding işlemlerini tamamladık. Şimdi isterseniz network portlarının yedekli
çalışıp çalışmadığını test edebilirsiniz.
Test aşamaları
Network portlarından eth0’ın LAN kablosunu çıkarıyoruz.
ifconfig -a #komutunu çalıştırıyoruz ve durumu
gözlemlediğimizde bond0 arayüzün UP ve RUNNING ve
eth1 arayüzüde RUNNING ise bondig konfigürasyonu düzgün
29. çalışıyor demektir.
Network portlarından eth1’ın LAN kablosunu çıkarıyoruz.
ifconfig -a #komutunu çalıştırıyoruz ve durumu
gözlemlediğimizde bond0 arayüzün UP ve RUNNING ve
eth0 arayüzüde RUNNING ise bondig konfigürasyonu düzgün
çalışıyor demektir.
Bonding konfigürasyon bilgilerini aşağıdaki komutla görebilirsiniz.
cat /proc/net/bonding/bond0
Bonding mode durumunu doğrulamak için aşağıdaki komutu
kullanabilirsiniz.
cat /sys/class/net/bond0/bonding/mode
Bonding mode durumunu değiştirmek istersek, “ifcfg-bond0”
konfigürasyon dosyasındaki “mode” kısmını değiştirebiliriz.
cat /etc/sysconfig/network-scripts/ifcfg-bond0 |grep -i
mode
Policy Details
Policy Name Code Description
balance-rr 0
Round-Robin policy for fault
tolerance
active-backup 1
Active-Backup policy for fault
tolerance
balance-xor 2
Exclusive-OR policy for fault
tolerance
Broadcast 3
All transmissions are sent on all
slave interfaces
802.3ad 4 Dynamic link aggregation policy
balance-tlb 5
Transmit Load Balancing policy
for fault tolerance
balance-alb 6
Active Load Balancing policy for
fault tolerance
Tablo 2.2 bonding policy değer tablosu
bonding yapılmış konfigürasyonları listelemek için aşağıdaki
komutu kullanabilirsiniz.
30. cat /sys/class/net/bonding_masters
Not: Sunucu tarafında bonding yaptıktan sonra, sunuclara bağlanmada bir sıkıntı
yaşıyorsanız ve bir yavaşlık söz konusu ise, ağ anahtarı tarafında LACP
yapılmadığından dolayıdır. Sunucu tarafında bonding yaptıktan sonra ağ anahtarı
tarafında da bonding yapılan portların LACP yapılması gereklidir.
31. BÖLÜM – 3
Cluster Konfigürasyonu İçin Sunucuların Hazırlanması
Bölüm 2’de anlatılan çalışmaları yaptıktan sonra, sunucularımıza(node’lar)
geri dönüyoruz ve cluster konfigürasyonu için gerekli iki rpm paketini Linux
DVD’sini veya sunucularımıza yönetim portları üzerinden uzaktan bağlanıp
“Linux.iso” dosyasını mount ederek yüklememiz gerekiyor.
Sunucuların yönetim ip adresinden cluster’a dahil etmek istediğimiz
sunucularımıza sırasıyla bağlanıp “Linux.iso” mount ediyoruz. Siz isterseniz Linux
DVD’sini de mount edebilirsiniz. Mount işleminin yaptıktan sonra aşağıdaki
komutları çalıştırarak rpm paketlerini cluster’a dahil edeceğimiz her bir node’a
yüklüyoruz.
# mount /dev/cdrom /media/ -o loop # mount edeceğiniz “.iso” dosyasının
yerine göre belirteceğiniz yol(path) değişiklikleri olabilir.
# cd /media/Packages/
Bu lokasyonda aşağıdaki komutları giriyoruz ve rpm paket yükleme işlemlerini
gerçekleştiriyoruz.
# rpm -ivh lvm2-cluster-2.02.87-6.el6.x86_64.rpm
# rpm -ivh gfs2-utils-3.0.12.1-23.el6.x86_64.rpm
Paketler aşağıdaki şekil 3.1’de görüldüğü gibi yükleneceklerdir. Bu
paketleri cluster’a dahil etmek istediğimiz herbir node üzerine yüklemeyi
unutmuyoruz. Bizim cluster yapımız iki node’dan oluştuğu için her iki node
üzerine rpm paket yükleme işlemlerini gerçekleştiriyoruz.
32. Şekil 3.1 Paketlerin node1 üzerine yüklenmesinin gösterimi
Şekil 3.2 Mount işlemi ve paketlerin node2 üzerine yüklenmesinin gösterimi
Şimdi aşağıda verilen komutları her iki node içinde uyguluyoruz. Bu
komutlar Linux Cluster’da istenmeyen servisleri disabled eder ve çalışması
gereken servisleri de yeniden başlatma (reboot) sonrasında otomatik olarak
enable eder.
# vi /etc/selinux/config # selinux kullanmak istemiyorsanız konfigürasyon
dosyasından SELINUX=disabled yazmalısınız. Bu işlem bütün selinux
fonksiyonlarını disable eder.
# chkconfig iptables off # firewall kapatmak istemiyorsanız cluster için
gerekli ip portlarının erişime açılmasını sağlamalısınız.
# chkconfig ip6tables off
# chkconfig acpid off
# chkconfig NetworkManager off # bu işlemi yaptığında network hatası
alabilirsiniz bu durumda grafik arayüz yerine komut satırından
/etc/sysconfig/network-script/ dizini altındaki ifcfg-eth dosyasını
düzenleyebilirsiniz.
# chkconfig luci on
# chkconfig ricci on
33. Şekil 3.3 Servislerin node1 üzerinde kapatılıp açılması işlemi
Şekil 3.4 Servislerin node2 üzerinde kapatılıp açılması işlemi
Bu işlemler sonrası her iki node’u yeniden başlatıyoruz(reboot).
# reboot
Not: NetworkManager kullanımı cluster node’lar üzerinde desteklenmiyor. Eğer
işletim sistemlerini kurarken Ne tworkManage rkurulmuşsa, ya
NetworkManagerkaldırmalısınısız yada disable etmelisiniz. Biz yukarda
görüldüğü gibi disable ediyoruz.
N o t : E ğ e r NetworkManagerçalışıyorsa yada chkconfig komutu ile
çalıştırılabilecek şekilde düzenlenmişse cman servisi çalışmayacaktır.
Sistem yeniden açıldıktan sonra luci ve ricci servisleri çalışacak ve kapanması
gereken servislerde kapanmış olacaktır. Hazırlıklara devam ediyoruz şimdi de her
iki node üzerinde hosts dosyalarına karşı node’un ip adres’lerini yazacağız. Bu
sayede her bir node, isimleri ile birbirlerine ulaşabileceklerdir. Eğer ip
adreslerini hosts dosyalarına yazmak istemiyorsanız bu işlemi DNS sunucu
üzerinde yapmanız gereklidir.
Biz node’larımızın ip adres’lerini hosts dosyalarına yazarak devam ediyoruz.
# vi /etc/hosts # cluster’a dahil edeceğimiz herbir node için bu işlemi
uyguluyoruz.
vi editörü açılınca aşağıdaki şekilde görüldüğü gibi ip adres-isim bağlantılarını
ilave ediyoruz ve vi editörünü kaydettikten sonra cat komutu ile durumu aşağıdaki
gibi görebiliriz.
34. Şekil 3.5 Node1 üzerinde ip adres’lerin hosts dosyasına yazılması
Şekil 3.6 Node2 üzerinde ip adres’lerin hosts dosyasına yazılması
Bu işlemleri de gerçekleştirdikten sonra node’ları birbirleri üzerinden isimleri ile
pingleyerek test ediyoruz. Aşağıdaki şekil 3.7 ve 3.8’de görüldüğü üzere
node’ların birbirine ping atabildiğini görüyoruz.
Şekil 3.7 Node1 üzerinde ping atma işlemi
Şekil 3.8 Node2 üzerinde ping atma işlemi
Şimdi daha ilerde sorun çıkarmaması içinricci servisinin kullandığı şifreyi
belirleyelim. Ricci servisi cluster konfigürasyon bilgilerinin güncelliğinden,
cluster node’larının haberdar olmasını sağlar.
# passwd ricci
35. Şekil 3.9 Node1 üzerinde ricci servisine şifre belirleme işlemi
Şekil 3.10 Node2 üzerinde ricci servisine şifre belirleme işlemi
Not: RedHat Enterprise Linux 6’dasystem-config-cluster ara yüzü
bulunmamaktadır. Bunun yerine daha kullanışlı bir web arayüzü bulunmaktadır.
Son olarak selinux ve firewall durumlarını kontrol edip cluster için çok önemli
olmasada bazı yerlerde yaşanan küçük sıkıntılardan dolayı zaman senkronizasyonu
için NTP’yi aşağıdaki komutları çalıştırarak her iki node içinde aktif hala
getiriyoruz.
# sestatus –v # komutu ile selinux durumunu kontrol edebiliriz.
# iptables –L # komutu ile firewall durumunu kontrol edebiliriz.
Şekil 3.11 Node1 üzerinde selinux ve firewall durumlarının gösterimi
36. Şekil 3.12 Node2 üzerinde selinux ve firewall durumlarının gösterimi
Zaman senkronizasyonu (Time synchronization) NTP;
# chkconfig ntpd on
# ntpdate pool.ntp.org
# /etc/init.d/ntpd start
Şekil 3.13 ntp ayarlarının yapılması işlemi
Buraya kadar olan adımları eksiksiz ve problemsiz gerçekleştirdiyseniz
grafik arayüz çalışacaktır. Artık cluster konfigürasyonuna grafik arayüzden devam
edebiliriz. Cluster konfigürasyonu ve yönetimini bölüm-4’te grafik arayüz
üzerinden anlattıktan sonra, bölüm-5’te de c c s komutu ile komut satırından
anlatıyor olacağız.
37. BÖLÜM – 4
Cluster Konfigürasyonu & Yönetimi
Linux cluster konfigürasyonunu ve yönetimini grafik arayüzden(Conga)
veya ccs komutuyla yapabilirsiniz. Cluster yönetimini sağlamak ve sürdürmek için
grafik arayüzü öğrendikten sonra komut satırından da bu işlemlerin yapılması ve
öğrenilmesinin, grafik arayüzde yaşanabilecek sıkıntılara rağmen sistemin
çalışırlılığının devamı ve kontrolü için gerekli olacaktır. Bu bölümde cluster
konfigürasyonlarını ve yönetimini grafik arayüzden anlatacağız. Bölüm 5’te de
komut satırına değiniyor olacağız.
Bu bölümde cluster konfigürasyonu ve yönetimini aşağıdaki gibi ele alıyor
olacağız;
Cluster Oluşturma(Create)
Quorum Disk Oluşturma (opsiyonel)
Data Diski Oluşturma
Resources
Failover Domains
Fence Devices
Services Groups
Cluster Konfigürasyon Dosyasını İnceleme
Grafik Arayüzden Varolan Cluster’a Node Ekleme-Kaldırma
A. Cluster Oluşturma(Create)
Şimdi tarayıcı (browser) adres kısmına https://ip-adres:8084/ adresini yazarak
yada ip adresi yerine isim girerek arayüze erişebiliriz. Eğer firewall aktif ise
uzaktan bağlanabilmek için 8084’nolu portun açılması gerekiyor.
Grafik arayüzün çalışmasını sağlayan servisler luci ve ricci servisleridir. Daha
öncede söylediğimiz gibi luci servisini başlatmadan önce cluster node’lar
üzerindeki “port 11111” portunun açık olması gerekiyor. Güvenlik duvarı
(Firewall) kapalı ise port açma işlemini gözardı edebilirsiniz.
Tarayıcı (browser) adres kısmına gerekli bilgileri yazdıysanız grafik arayüz
38. aşağıdaki şekil 4.1’deki gibi karşınıza gelecektir.
Şekil 4.1 Cluster arayüz ekranına giriş
Username kısmına root yazalım. Password kısmına da root password’ünü
yazarak cluster konfigürasyon arayüz ekranına giriş yapıyoruz. Luci cluster
konfigürasyon ekranı aşağıdaki gibi gelecektir.
Aşağıdaki şekil 4.2’de görüldüğü gibi “Homebase” sekmesinde herhangi
bir şey görünmüyor çünkü herhangi bir cluster konfigürasyonu yapmadık. Ayrıca
sağ üst tarafta “About” sekmesini tıklayarak cluster sistemi hakkında bilgileri
görebilirsiniz. “Admin” sekmesini tıkladığımızda ise luci sunucu loglama
konfigürasyon ayarlarını istediğimiz bir şekilde değiştirebileceğimiz ve luci
grafik arayüzünü kullanmasını istedğimiz kullanıcıları oluşturup izinlerini
belirleyebileceğimiz bir bölüm karşımıza çıkmaktadır. Bu şekilde farklı
kullanıcılarında cluster konfigürasyon arayüzüne erişebilmesini sağlayabiliriz.
Not: luci için boşta bekleme süresi vardır. 15 dakika herhangi bir şey yapmadan
beklerseniz zaman aşımından dolayı oturum otomatik kapanacaktır.
39. Şekil 4.2 Luci cluster konfigürasyon arayüzü
Cluster konfigürasyonunu başlatmak için “Manage Clusters” sekmesini
tıklıyoruz. Karşımıza aşağıdaki ekran gelecektir. Ekranda da görüldüğü gibi bize
3 seçenek sunmaktadır;
“Add” var olan cluster konfigürasyonuna yeni bir node eklemek
istediğimizde kullanabileceğimiz sekmedir.
“Create” yeni bir cluster yapısı oluşturmak için kullanabileceğimiz
sekmedir.
“Remove” sekmesi kurduğumuz bir cluster yapıyı kaldırmak için
kullanabileceğimiz sekmedir.
Şimdi biz yeni bir cluster yapısı oluşturacağımız için“Create” diyerek Cluster
konfigürasyonuna devam ediyoruz.
40. Şekil 4.3 Manage clusters sekmesinin gösterimi
“Create” sekmesini tıkladığımızda karşımıza aşağıdaki şekil 4.4’deki ekran
gelecektir.
Şekil 4.4 Cluster oluşturma ekranı
Cluster yapımızı kurmak için belirlediğimiz bir cluster ismini vererek
başlıyoruz. Ben test amaçlı olduğu için cluster ismini “mycluster” olarak
belirledim. Sizlerde belirlediğiniz bir ismi verebilirsiniz. Daha sonra tüm
node’larda aynı password’ün kullanılması için “use the same password for all
nodes” kutucuğunu işaretliyoruz. Yüksek Erişilebilirlik(High Availability) için
gerekli paketleri önceki bölümlerde yüklediğimiz için burada “Use Locally
Installed Packages” kutucuğunu işaretli olarak bırakıyoruz. Eğer cluster yazılım
paketlerinin güncellenmesini istiyorsanız “Download Packages” seçeneğini
41. işaretlemelisiniz. Birde en altta “Enable Shared Storage Support” kutucuğu
işaretledikten sonra “create cluster” diyoruz ve cluster’ı aşağıdaki şekil 4.5’de
görüldüğü gibi oluşturmaya başlıyoruz.
Şekil 4.5 Cluster oluşturma işlemi gösterimi
Ve cluster’ı oluşturduk. Aşağıdaki şekil 4.6’da görüldüğü gibi “mycluster”
adında 2 node’lu cluster sistemimizi görmekteyiz. Node’ların status bölümüne
baktığımızda cluster üyesi olduklarını görebiliyoruz. Bu yapıyı gerektiğinde 16
node’lu bir sisteme dönüştürebileceğimizi söylemiştik.
Şekil 4.6 Cluster bilgilerinin gösterimi
Not: Eğer ricci servisi herhangi bir node üzerinde çalışmıyorsa, cluster oluşturma
işlemi başarısız olacaktır.
Cluster oluşturma işlemini tamamlandıktan sonra yukardaki şekil 4.6’da
42. görüldüğü üzere cluster yapının yönetimi adına, artık cluster’daki herhangi bir
node’u silebilir(Delete), yeniden başlatabilir(Reboot), cluster’dan çıkarabilir ve
cluster’a dahil edebilir yada cluster’a yeni bir node ekleme(Add) işlemini
yapabilirsiniz.
Cluster yapısını oluşturduk ancak hala yapılacak çok işimiz var. Hatta
cluster konfigürasyonalarının ince ayarlarına yeni başlıyoruz diyebilirim.
Yukardaki ekranda görüldüğü gibi cluster yapı oluşturulduktan sonra yeni
sekmeler ortaya çıktı. Şimdi bu sekmeleri gerektiği gibi inceleyerek sistemimizin
konfigürasyonlarına devam ediyoruz.
B. Quorum Disk Oluşturma (opsiyonel)
Failover-server için Linux cluster yapının bize sunduğu network power
switchlerimizi kullanacağımız için Quorum Disk oluşturma işlemini opsiyonel
olarak gösteriyoruz. Linux cluster sunucularda failover için önerilen yapı fence
device mantığının kullanımıdır. Quroum disk oluşturma işlemi için daha önceden
hazırladığım her iki sunucunun da fiber interface’i üzerinden görebildiği “sdb”
diskini kullanacağım. Sizin altyapınızda ISCSI yapı mevcutsa onu da
kullanabilirsiniz. Bu diski, quorum diski olarak özel bir format ile hazırlamak
gerekiyor.
Cluster’daki herhangi bir node üzerinden partition oluşturma işlemini aşağıdaki
şekil 4.7’de görüldüğü gibi gerçekleştiriyoruz.
43. Şekil 4.7 quorum disk için partition oluşturma işlemi
Partition oluşturma işlemlerini tamamlandıktan sonra, quorum disk oluşturmak
için, aşağıdaki komutu kullanabilirsiniz.
# mkqdisk -c /dev/sdb1 -l qdisk
44. Şekil 4.8 Quroum disk oluşturma işlemi
Oluşturduğumuz quorum diskimizi aşağıdaki komutu çalıştırarak kontrol ediyoruz.
# mkqdisk –L
Şekil 4.9 mkqdisk -L komutunun gösterimi
Yukardaki şekilde görüldüğü üzere quorum diskimiz hazır. Şimdi cluster grafik
ara yüzü kullanarak mycluster adlı cluster’ımıza bu diski atayalım.
Şekil 4.10 cluster’a quroum disk tanıtma işleminin gösterimi
Quorum diskimizi cluster yapıya dahil etmek için;
45. Configure sekmesini tıklıyoruz.
QDisk sekmesini tıklıyoruz. ve quorum diski konfigürasyonu
yapacağımız ekran karşımıza gelir.
Use a Quorum Disk kutucuğunu işaretliyoruz.
By Device Labelkutucuğunuda işaretleyip altındaki bölüme
label olarak belirlediğimiz “qdisk” adını yazıyoruz.
“Apply” butonuna tıklıyoruz ve quorum disk konfigürasyonunu
tamamlamış bulunuyoruz.
# clustat # Komutu ile cluster’ın durumunu görelim.
Şekil 4.11 Quroum disk eklenmiş cluster yapının gösterimi
Quorum diskimizi cluster’daki node’lara tanıttıktan sonra,
“/etc/cluster/cluster.conf” dosyasında aşağıda belirtildiği gibi küçük bir ekleme
yapıyoruz.
# vi /etc/cluster/cluster.conf # vi editörü ile konfigürasyon dosyasını
açıyoruz ve “<totem token="21000"/>” cluster’daki herbir node üzerinde bu
eklemeyi gerçekleştiriyoruz.
Şekil 4.12 cluster.conf dosyasına ekleme işleminden sonraki gösterim
Biz kuracağımız cluster yapı içerinde quorum disk kullanmayacağımız için quorum
diski bilmek açısından opsiyonel olarak quorum disk oluşturma işlemlerini adım
adım anlatmış bulunuyoruz. Şimdi cluster sistemimize kaldığımız yerden devam
46. edelim.
C. Data Diski Oluşturma
Şimdi cluster sunucuların birlikte aynı anda yazıp kullanacakları data
alanını oluşturacağız. Bu işlem içincli ara yüzünü yani komut satırını
kullanıyoruz. Bölüm 2’de veri depolama ünitesinden verdiğimiz ve node’lara
tanıttığımız diski cluster yapının kullanımına sunmak için hazır hale getireceğiz.
Bu alanı cluster’a dahil olan sunucular kullanabilecek ve görecekler. Zaten Fiber
yapı üzerinden ortak alan olarak belirlediğimiz diskimizi diğer bir tabirle LUN’u
fiziksel olarak cluster’a dahil sunuculara göstermiştik.
Data alanı olarak cluster yapıya vereceğimiz diskimizin yapısını LVM
yapacağız çünkü ilerde disk alanının büyütülmesi istendiğinde kolaylıkla disk
alanının arttırımını yapabiliyor olacağız.
Not: Veri Depolama ünitesinden verilen disk 2TB’tan büyükse “fdisk” komutu
yerine “parted” komutu ile diskin formatı GPT olarak değiştirilmelidir. Çünkü
2TB’dan büyük diskleri MBR disk formatı desteklememektedir. Aksi takdirde
örneğin veri depolama ünitesinden disk olarak 10TB lun verdiğinizi düşünürsek.
Eğer GPT formatına geçmeden MBR disk formatı ile formatlarsanız 10TB yerine
diskinizi 2TB görüyor ve kullanabiliyor olabileceksiniz.
Not: Data alanı olarak verdiğiniz disk üzerinde gfs2 dosya sistemi (file system)
kullanacaksanız LVM yapmalısınız.
Bizim data diskimiz 2TB’tan daha küçük olduğu için “fdisk” komutu ile
işlemlerimize devam ediyoruz. Bu bölümün sonuna doğru2TB’tan daha büyük
diskler kullanan arkadaşlar için “parted” komutunun kullanımına da değineceğim.
# fdisk /dev/mapper/3600a0b80005a0e42000012fa52a467e7
47. Şekil 4.13 Disk üzerinde partition oluşturma işlemi
Yukarıdaki komut çıktısı yorumlandığında ;
- Command (m for help): bölümünde “add new partition” anlamına gelen “n”
tuşuna basılır ve ardından “Enter” tuşuna basılır.
- Command action: bölümünde “p” tuşuna basılır ve ardından “Enter” tuşuna
basılır.
- Partition number: bölümünde “1” tuşuna basılır ve ardından “Enter” tuşuna
basılır.
- First cylinder (1-1305, default 1): bölümünde herhangi bir değer verilmeden ön
tanımlı olan değer kabul edilir ve “Enter” tuşuna basılır.
- Last cylinder or +size or +sizeM or +sizeK (1-1305, default 1305): bölümünde
herhangi bir değer verilmeden ön tanımlı olan değer kabul edilir ve “Enter” tuşuna
basılır.
partition oluşturulduktan sonra “t” tuşuna basılarak ilgili bölümün tipi
seçilmelidir. Bunun için aşağıdaki şekilde görüldüğü gibi işlemlere devam
ediyoruz.
48. Şekil 4.14 Disk partition oluşturmadan sonraki type seçim işlemi
- Hex code (type L to list codes): bölümünde oluşturulacak disk bölümü tipinin
hex kodu belirlenmelidir. Lvm disk dosya sisteminin hex kodu “8e” dir. Hex code
(type L to list codes): bölümüne “8e” yazılarak “Enter” tuşuna basılır.
- Son olarak işlemler tamamlandıktan sonra, işlemlerin kaydedilmesi için “w”
tuşuna basılıp “Enter” tuşuna basılarak işlemler tamamlanır.
Disk bölümü oluşturuldu. Oluşturulan disk bölümünü “/dev/…” dizini altında
görülebilir. Bunun için aşağıda belirtilen komutu çalıştırabilirsiniz.
# ll /dev/mapper/3600a0b80005a0e42000012fa52a467e7*
Şekil 4.15 Diskimiz ve oluşturulan partition
Komut çıktısı yukarıdaki gibidir. Görüldüğü gibi disk bölümü oluşturulmuştur.
Şimdi LVM yapısını oluşturmaya başlayabiliriz. LVM yapısının ilk aşaması
olarak aşağıdaki gibi fiziksel volume oluşturuyoruz.
# pvcreate /dev/mapper/3600a0b80005a0e42000012fa52a467e7p1 #
partition oluşturduğumuz diskimizi yada varsa disklerimizi fiziksel volume yapıyoruz
Şekil 4.16 Fiziksel volume oluşturma işlemi
49. Oluşturduğumuz fiziksel volume’ü “pvdisplay” komutuyla aşağıdaki şekil
4.17’deki gibi görebiliriz. LVM yapısını oluşturma işlemine volume group
oluşturarak devam ediyoruz. Volume group oluşturduktan sonrada birden fazla
fiziksel diskiniz varsa bunları volume group içerisine atıyoruz.
Şekil 4.17 pvcreate komutu sonrası oluşturulan fiziksel volume gösterimi
# vgcreate –c y vg_dbcluster
/dev/mapper/3600a0b80005a0e42000012fa52a467e7p1 # Volume group
oluşturma ve daha önce oluşturduğumuz fiziksel volume’ü , volume group
içerisine dahil etme işlemi. Birden fazla fiziksel volume varsa onları da
oluşturduğunuz volume group’a dahil etmeniz gerekiyor.
Şekil 4.18 Volume group oluşturma işlemi
Oluşturduğumuz volume group’u “vgdisplay” komutuyla aşağıdaki şekil 4.19’daki
gibi görebiliriz. Fiziksel volume ve volume group oluşturma işlemleri
tamamlandığına göre artık mantıksal(logical) volume yada volume’ler
oluşturabiliriz.
50. Şekil 4.19 vgcreate komutu sonrası oluşturulan volume group gösterimi
# lvcreate -l 100%FREE -n lv_db vg_dbcluster
Şekil 4.20 Logical volume oluşturma işlemi
Oluşturduğumuz mantıksal(logical) volume lvdisplay komutuyla aşağıdaki şekil
4.21’deki gibi görebiliriz. Mantıksal(logical) volume’de oluşturduğumuza göre,
oluşturduğumuz mantıksal volume’ü kullanmak istediğimiz dosya sistemi (file
system) ile formatlayabiliriz.
51. Şekil 4.21 lvcreate komutu sonrası oluşturulan logical volume gösterimi
# mkfs.gfs2 -p lock_dlm -t mycluster:gfs2 -j 4 /dev/mapper/vg_dbcluster-
lv_db # Eğer dosya sistemi olarak gfs2 kullanmak istiyorsanız diskinizi gfs2
gerektiren parametrelerle formatlamalısınız. Kullandığınız isimlerde(vg,lv) büyük
harf, küçük harf gibi durumlara dikkat etmek gerekiyor. Benim cluster’ın ismi
“mycluster” olduğu için “mycluster” yazılı siz de kendi clusterınızın adını
yazmalısınız.
Şekil 4.22 gfs2 dosya sistem ile formatlama işlemi
# mkfs.ext4 /dev/mapper/vg_dbcluster_lv_db # ext4 dosya sistemini
kullanmak istiyorsanız. Formatlama işlemini burada belirtildiği gibi
gerçekleştirmelisiniz.
52. Şekil 4.23 ext4 dosya sistem ile formatla işlemi
Formatlama işinden sonra kullanıma hazır bir disk elde edilir. Artık diskimiz
cluster yapının kullanımına hazırdır.
Şimdi başta kısaca bahsettiğimiz GPT formatına geri dönelim…
Sisteminizde eğer 2TB’tan daha büyük disklere ihtiyacınız varsa fdisk
komutu ile disk yönetimi yapamazsınız. Eğer yapmaya çalışırsanız da başta
söylediğim gibi diskiniz ne kadar büyük olursa olsun formatladıktan sonra sadece
2TB kullanılabilir disk görüyor olacaksınız.
2TB’tan daha büyük lun’lar oluşturamayacak mıyız?
Peki bu sorunu nasıl çözebiliriz…
İlk başta var olan disklerimizi ve partition’larımızı incelemek adına
aşağıdaki komutu çalıştırabilirsiniz.
# ll /dev/mapper/
53. Şekil 4.24 Sunucu üzerinde bulunan diskler ve partition’ların gösterimi
Ekran çıktısında görüldüğü gibi vg_node1.. ile başlayanlar bizim local
diskimiz ve diskimiz üzerinden işletim sistemi kurulumunda oluşturduğumuz
partition’larımız. wwid numarası ile başlayan bizim veri depolama ünitesinden
cluster’daki node(sunucu)’larımıza tanıttığımız diskimizdir.
Parted komutu ile hem GPT hemde MBR formatında diskler oluşturabilir ve
yönetebilirsiniz. Eğer diskiniz 2TB’tan büyükse zaten fdisk komutu yerine parted
komutunu kullanmak zorundasınız.
# parted /dev/mapper/3600a0b80005a0e42000012fa52a467e7 #parted
komutunu üzerinde işlem yapacağımız diskimizi belirterek çalıştırdığımızda
aşağıdaki ekran çıktısı ile karşılaşıyoruz. Ekran çıktısında görüldüğü gibi help
komutunu çalıştırırsak, parted bölümünde kullanabileceğimiz komutların listesini
bizlere sunacaktır.
Şekil 4.25 parted komutunun çalıştırılması
54. Şekil 4.26 help komutunun çıktısı
“Parted” komutuyla diskimizin yönetimine başladığımıza göre print komutu
anlamına gelen “p” tuşuna basıp enter diyoruz ve diskimizin bilgilerine
ulaşıyoruz.
Şekil 4.27 diskimizin bilgilerinin gösterimi
Şekilde görüldüğü gibi partition table “msdos” olarak gözüküyor yani MBR
formatında demektir. Eğer diskiniz 2TB’tan büyükse yada diskiniz 2TB’tan küçük
olsada GPT formatını kullanmak istiyorsanız partition table bölümünde GPT
yazmasını sağlamalısınız. Bunun için aşağıdaki verilen komutu kullanabilirsiniz.
(parted) mklabel gpt
55. Şekil 4.28 Diskimizin GPT formatına dönüştürülmesi ve gösterimi
Şekilde de görüldüğü gibi “mklabel” komutunu çalıştırdığımızda işleme devam
etmek ister misin sorusuna “yes” cevabının verirseniz disk türü GPT olarak
değişecektir. Formatı GPT yaptığımıza göre artık istediğimiz gibi partition yada
partition’lar oluşturabiliriz.
(parted) mkpart primary 1 5G
Şekil 4.29 Diskimiz üzerinden partition oluşturma işlemi
Yukardaki şekilde görüldüğü gibi, 10GB diskimizden 5GB’lık bir partition
oluşturma işlemini gerçekleştiriyoruz. Geriye kalan kapasiteyide istediğimiz gibi
başka bir partition oluşturabiliriz.
Oluşturduğumuz partition’ı silmek için; aşağıdaki komutta “1” sayısı partition
number’dır. Birden fazla partition varsa ve hangisini silmek istiyorsanız onun
partition number’ını girmelisiniz.
(parted) rm 1
56. Şekil 4.30 partition silme işlemi
Biz elimizdeki diskimizi tek partition yapmak istiyoruz. Diski tek parça görmek
için aşağıdaki komutu kullanabilirsiniz.
(parted) mkpart primary ext4 1 -1
Şekil 4.31 Diskimizi tek partiiton yapma işlemi
Partition oluşturma işlemlerini tamamladığımıza göre parted bölümünden
çıkıyoruz.
(parted) quit
# fdisk -l # kontrol amaçlı “fdisk -l” komutunu çalıştırdığınızda GPT formatlı
bir partition oluşturulduğunu görüyor olacaksınız.
Diskimizi kullanılabilir bir hale getirmek için son aşama olarak kullanmak
istediğimiz dosya sistemi (file system) formatıyla diskimizi formatlama işlemini
gerçekleştiriyoruz.
# mkfs.ext4 /dev/mapper/3600a0b80005a0e42000012fa52a467e7p1
57. Şekil 4.32 ext4 dosya sistem ile formatla işlemi
Yukardaki şekilde görüldüğü gibi ext4 dosya sistemi ile formatlama işleminide
yaptığımıza göre cluster yapıda ortak alan olarak kullanacağımız diskimizi
kullanılabilir hale getirmiş oluyoruz. Diskimiz hazır hale geldiğine göre cluster
yapıya dahil ederek mysql veri tabanımızın kullanımına sunabiliriz.
Örnek olması açısından diskimizi cluster yapıya dahil etme işlemini cluster.conf
dosyası üzerinden yaparak grafik arayüz olmadan da işlemlerimizi
yapabileceğimizi göstereceğim.
Öncelikli olarak cluster yapıyı aşağıdaki komutları çalıştırarak durduruyoruz. Bu
durdurma işlemini cluster yapıdaki her bir makinede gerçekleştiriyoruz.
# /etc/init.d/rgmanager stop
# /etc/init.d/clvmd stop
# /etc/init.d/cman stop
58. Şekil 4.33 cluster servislerini durdurma işlemi
Cluster servislerini durdurma işlemlerini tamamladıktan sonra “vi” komutuyla
cluster.conf dosyamızda fs device bölümündeki ortak alan olarak belirlediğimiz
diski path(yolunu) “/dev/mapper/3600a0b80005a0e42000012fa52a467e7p1”
olarak değiştiriyoruz. Bu işlemin cluster’a dahil her bir node üzerindeki
cluster.conf dosyasında gerçekleştirilmesi gerekiyor. Düzenlemeyi yaptıktan
sonra “vi” editöründen “wq!” çıkıyoruz. Cluster konfigürasyon dosyası üzerinde
değişiklikleri yaptığımıza göre cluster servislerini çalıştırıyoruz.
# vi /etc/cluster/cluster.conf
# /etc/init.d/cman start
# /etc/init.d/rgmanager start
59. Şekil 4.34 cluster servislerini çalıştırma işlemi
# watch clustat
Şekil 4.35 watch komutu gösterimi
Yeri gelmişken “watch” komutu yukardaki gibi izlemek istediğimiz komutun
çıktılarını anlık olarak görmemizi sağlar. Bu şekilde cluster servisinin
çalışırlılığının anlık olarak izleyebiliyoruz. Yukarda görüldüğü gibi node2 online
ve cluster servisimiz node2 üzerinde çalışıyor.
Node2 üzerinde yaptığımız işlemleri node1 üzerinde de düzgün bir şekilde
yapmadığımız için node1 offline olarak gözükmektedir. Aynı işlemleri node1
üzerinde yaparken “watch” komutuyla durumu izleyebilirsiniz.
cluster.conf dosyasında değişiklikler yapabilme adına bir örnek verdikten sonra
cluster konfigürasyonuna kaldığımız yerden devam ediyoruz.
D. Resources Konfigürasyonu
Cluster yapıda çalıştırmak istediğimiz mysql veritabanı için gerekli
kaynakların(resources) oluşturulması işlemidir. Eğer siz cluster yapıda
çalıştırmak istediğiniz uygulama farklıysa, uygulamanın gerektirdiği şekilde
kaynaklar(resources) oluşturmalısınız.
Mysql veritabanını cluster olarak çalıştırmak için gerekli kaynaklar(resources);
Virtual ip adres
Cluster’da çalışan uygulamanın verilerinin yazılacağı ortak alan
60. Mysql veritabanı servisinin çalışırlılığının kontrolü için gerekli
script kaynak(resources) oluşturma işlemi olmak üzere 3 tane
kaynak oluşturuyoruz.
Cluster grafik arayüzdenResources sekmesini tıklıyoruz ve Add diyerek
kaynak oluşturma işlemine başlıyoruz.
ilk olarak konfigürasyona floating ip adres ekliyoruz yani diğer bir deyimle
virtual ip adres. Clusterdaki aktif node hangisiyse o node üzerine ağ trafiğini
yönlendiren cluster ip adresi diyebiliriz. Aktif olan node üzerinde “ip a”
komutunu çalıştırdığımızda cluster ip adresini secondary olarak görüyor olacağız.
Yani aynı network portu üzerinde iki tane ip adresi olacak bunlar; sunucunun
kendi ip adresi ve cluster ip adresidir. Şimdi aşağıdaki şekilde de görüldüğü gibi
virtual ip adresi ekleme işlemini gerçekleştiriyoruz.
Add tıkladıktan sonra IP Address kaynağını(resource) aşağıdaki
şekilde de görüldüğü gibi seçiyoruz.
IP Adress bölümüne virtual ip adres olarak belirlediğimiz ip
adresini giriyoruz.
Submit butonunu tıklıyoruz ve ip adres kaynak ekleme işlemini
tamamlıyoruz.
Şekil 4.36 virtual ip adres oluşturma işlemi
61. İkinci olarak cluster verilerinin yazılacağı ortak alanı oluşturmalıyız. Cluster
verilerinin yazılması için gfs2 yada ext4 dosya sistem (File system) türlerinden
hangisini kullanacaksanız ona göre seçim yapmalısınız.
Dosya sistemi (File system) olarak ext4 kullanıyorsanız aşağıdaki şekildeki gibi
kaynak (resource) oluşturabilirsiniz;
Add tıkladıktan sonra Filesystem kaynağını(resource) seçiyoruz.
Name bölümüne paylaşılmış alanı tanımlamak adına “db_data”
adını veriyoruz.
Filesystem Type bölümünü ext4 olarak seçiyoruz.
Mount Point bölümüne mysql veritabanı verilerinin yazılacağı yolu
göstermek adına “/var/lib/mysql” yolunu yazıyoruz.
Device, FS Label, or UUID bölümüne paylaşım alanı olarak
oluşturduğumuz veri diskinin yolunu gösteriyoruz. Veri diskini
oluştururken isimlendirmede ve konfigürasyonda farklılık
olabileceği için, oluşturduğunuz veri diskinin yolunu
göstermelisiniz.
Force Unmount, Force fsck, Use Quick Status Checks, Reboot
Host Node if Unmount Fails kutucuklarını işaretliyoruz.
Submit butonunu tıklıyoruz ve ext4 dosya sistemli kaynak ekleme
işlemini tamamlıyoruz.
62. Şekil 4.37 ext4 dosya sistemli ortak alan oluşturma işlemi
Dosya sistemi (File system) olarak gfs2 kullanıyorsanız aşağıdaki şekildeki gibi
kaynak (resource) oluşturabilirsiniz;
63. Şekil 4.38 gfs2 dosya sistemli ortak alan oluşturma işlemi
Son olarak cluster mimari de yüksek erişebilirlik(HA) olarak kullanacağımız
mysql veritabanınnı servisinin çalıştırılması için gerekli olan script resource
oluşturuyoruz;
Add tıkladıktan sonra Script kaynağını(resource) seçiyoruz.
Name bölümüne mysql veritabanını tanımlamak adına “mysqld”
adını veriyoruz.
Full Path to Script File bölümüne mysql veritabanının servisini
göstermek adına “/etc/init.d/mysqld” yolunu yazıyoruz.
Submit butonuna tıklıyoruz ve script kaynak ekleme işlemini
tamamlıyoruz.
64. Şekil 4.39 script resource oluşturma işlemi
Cluster mimaride mysql veritabanını çalıştırmak için gerekli olan kaynak
oluşturma(resources) işlemlerini tamamladık. Eğer oluşturmuş olduğunuz
kaynaklardan(resources) herhangi birinde değişiklik yapmak isterseniz, değişiklik
yapmak istediğiniz kaynağı tıklayıp gerekli gördüğünüz değişiklikleri yaptıktan
sonra Apply butonuna basıp yapılan değişiklikleri tamamlayabilirsiniz. Ayrıca
herhangi bir kaynağı silmek istediğinizde kaynağın yanındaki kutucuğu işaretleyip
Delete etmelisiniz. Oluşturduğumuz kaynakları (resources) aşağıdaki şekildeki
gibi görebiliriz. şekilde görüldüğü üzere kaynaklar kulanımda değil “In use : no”
olarak görülmektedir. Çünkü şuana kadar sadece kaynakları oluşturma işlemlerini
gerçekleştirdik.
Şekil 4.40 oluşturulan kaynakların gösterimi
E. Failover Domains Konfigürasyonu
Failover domains cluster node’larının arasında öncelik sırası oluşturmak
65. diyebiliriz. Cluster, aktif node üzerinde çalışırken oluşabilecek herhangi bir hata
sonrasında cluster servislerini üzerine alacak node’un belirlenmesidir. Örneğin
cluster yapımız A, B ve C olmak üzere 3 node üzerinde yapılandırıldığını
düşünelim. Bunlardan A aktif node olarak çalışıyor ve failover domain
konfigürasyonunda öncelik sırasını A-C-B olarak belirledik. Eğer aktif node
olarak çalışan A herhangi bir hata sonucu cluster servislerini kapattığında, öncelik
sırasına göre cluster servislerini üzerine alacak node C dir.
Not: Failover domain cluster yapının çalışması için zorunlu bir gereksinim
değildir.
N ot : Failover domainde yapılacak herhangi bir değişiklik çalışan cluster
servislerini etkilemez.
Failover domain özellikleri;
Prioritized: cluster servislerinin failover olacağı node’ların
önceliklendirilmesi için seçilmesi gerekiyor.
Unrestricted(kısıtlanmamış): Cluster servisleri cluster içerisindeki
hernangi bir node üzerinde çalışır ve aktif node hata ile karşılaştığında
cluster servisleri cluster içerisindeki herhangi bir node üzerine atanır.
Default durumunda yani herhangi bir failover konfigürasyonu
yapılmadıysa, failover domains unrestricted’dır.
Restricted(kısıtlı): Eğer restricted özelliği seçilirse sadece
belirlenmiş node’lar üzerinde cluster servisleri çalışabilir. Restricted
failover domain olarak belirlenmiş node’ların hiçbirisine
ulaşılamıyorsa, cluster servisleri başlatılamaz.
No Failback: Önceliklendirilmiş bir node üzerinde cluster servisleri
başarısız olduktan sonra tekrar ulaşılabilir olduğunda cluster
servislerini üzerine almaması için seçilmiş olması gerekiyor.
Failover domains’den bahsettiğimize göre artık failover domains
konfigürasyonunu yapabiliriz. Cluster konfigürasyon arayüzden Failover Domains
sekmesine geçiyoruz ve Addsekmesini tıklıyoruz ve adım adım konfigürasyonu
gerçekleştiriyoruz;
66. Name kutusuna herhangi bir isim yazıyoruz.
Cluster node’ları arasında failover önceliğini aktif etmek için
Prioritized kutucuğunu işaretliyoruz.
Sadece failover domain içerisindeki node’ların failover
yapabilmesi için Restricted kutucuğunu işaretliyoruz.
1. Öncelikli node ulaşılabilir olduğunda tekrar servisleri üzerine
almaması için No Failback kutucuğunu işaretliyoruz.
Failover domain’e dahil etmek istediğimiz node’lar içinMember
kutucuğunu işaretliyoruz ve failover domaine dahil edilen her bir
node’un Priority kutucuğundaki öncelik ayarlarını yapıyoruz.
V e C re a t e di yer ek Failover Domains konfigürasyonlarını
tamamlıyoruz.
Şekil 4.41 failover domain konfigürasyonu
Aşağıdaki şekilde görüldüğü üzere Failover Domains konfigürasyonunu
tamamladık. Eğer Prioritized, Restricted,yada No Failbacközelliklerini
değiştirmek isterseniz. Oluşturmuş olduğunuz failover domains konfigürasyonunu
tıklıyoruz ve kutucuk işaretleme yada işaret kaldırma işlemini yaptıktan sonra
Update Properties diyoruz. Eğer failover domains’e yeni node dahil etmek veya
failover domain’den node çıkarmak isterseniz Member kutucuğunu işaretlemek
67. yada kaldırmalısınız ve öncelik ayarlarında da değişiklikler yaptıktan sonra
Update Settings tıklamalısınız. Failover domain’i silmek istediğinizde
oluşturduğunuz failover domains işaretleyip Delete etmelisiniz.
Şekil 4.42 oluşturulan failover domains konfigürasyonu gösterimi
F. Fence Devices Konfigürasyonu
Fence Devices konfigürasyonu her linux temelli cluster bir yapı
gerçekleştirmek için önemli bir komponenttir. Fencing gerçekleştirmenin ana
amacı cluster yapısında veri bütünlüğünü(data integrity) sağlamaktır. Veri
bütünlüğü derken anlatmak istediğimiz aslında, sadece bir node cluster servisini
çalıştırabilir ve aynı zamanda sadece bir node cluster servisine erişebilir.
Böylece failover süreçleri esnasında cluster servisinin bir node’dan diğer node’
geçmesini sağlarken, aynı anda iki node’unda verilere erişimini ve veri
bozulmalarını(simultaneously accessing the same data and corrupting it) önler.
Böylece Fence devices olası oluşabilecek bütün hatalara karşı veri bütünlüğünü
sağlar.
Cluster için fence device oluşturma, güncelleme, silme gibi işlemleri
yapabileceğimiz Fence Devices sekmesini tıklıyoruz. Cluster konfigürasyonu
adına herhang bir fence device oluşturulmadığı için hiçbir yapılmış ayar
bulunmamaktadır. Şimdi network power switch ile yedeklilik oluşturacak şekilde
fence device oluşturma işlemine geçebiliriz.
Öncelikle apc network power switch’lerimize serial konsoldan bağlanıp,
SSH portunu açıyor ve ağ üzerinden bir ip adres veriyoruz ve network power
switchlerimizi yeniden başlatıyoruz(reboot) ediyoruz. Network power
switchleriniz açıldıktan sonra, verdiğiniz ip adresi ile http üzerinden bağlanıp
özel olarak istediğiniz bir ayar varsa yapabilirsiniz. Biz herhangi bir şey
yapmadan devam ediyoruz.
68. Not: Bazı eski APC pdu’lar SHH desteklemiyor ve fence_apc ile çalışmıyor.
Bundan dolayı bu pdu’larda fence agent olarak fence_apc_snmp kullanarak SNMP
ile çalışmasını sağlayabilirsiniz.
1) Fence_apc agent konfigürasyonu
Fence Devices sekmesinden fence device olarak apc power switch
kullandığımız için APC Power Switch seçiyoruz ve aşağıdada görüldüğü gibi
fence_apc agent oluşturma işlemlerini gerçekleştiriyoruz.
Add tıkladıktan sonra APC Power Switch seçiyoruz.
Name bölümüne apc power switch tanımlamak adına “pwr01”
adını veriyoruz. İkinci apc power switch’e de “pwr02” adını
veriyoruz.
IP Addresss or Hostname bölümüne apc power switch için
belirlediğimiz ip adresini giriyoruz.
Login bölümüne apc power switch’e bağlantı yaptığımız kullanıcı
bilgisini giriyoruz.
Password bölümüne apc power switch’e bağlantı yaptığımız
kullanıcının şifresini giriyoruz.
Submit butonuna tıklıyoruz ve fence_apc agent oluşturma işlemini
tamamlıyoruz.
70. Şekil 4.44 apc power switch 2 oluşturma işlemi
Power switch tarafında yedeklilik sağlaması için pwr01 ve pwr02 adlı iki
tane network power switchimizin fence device olarak konfigürasyonunu aşağıdaki
şekil 4.45’teki gibi görebiliriz. Aşağıdaki şekilde de görüldüğü üzere fence_apc
agentlar clusterdaki node’lar tarafından kullanımda değil. Fence_apc agent’lar
hazır olduğuna göre artık clusterdaki node’larımıza tanıtmaya geçiyoruz. Cluster’a
dahil herbir node için fencing konfigürasyonu yapılmalıdır.
71. Şekil 4.45 oluşturulan fence_apc agentların gösterimi
Node 1 için fencing konfigürasyonu;
Nodes sekmesini tıkladıktan sonra clusterdaki herbir node üzerinde fencing
konfigürasyonu yapmak için;
Add Fence Method sekmesini tıklıyoruz
Method Name bölümüne node üzerindeki fence method tanımlamak
adına “Method_1”adını veriyoruz.
Submit butonunu tıklıyoruz fence method oluşturma işlemini
tamamlıyoruz.
Şekil 4.46 fence method oluşturma işlemi
Method_1 adlı oluşturduğumuz fence method’a fence_agentları ekleme işlemlerini
yapıyoruz.
Add Fence Instance tıklıyoruz ve oluşturduğumuz fence device’ları
sırasıyla seçip port bilgilerini girdikten sonra aşağıdaki gibi fence
device oluşturma işlemini tamamlıyoruz. Bu işlemleri diğer
node’lar üzerinde de yapmayı unutmuyoruz.
72. Şekil 4.47 node1 üzerinde fence device oluşturma işleminden sonra gösterimi
Node 2 için fencing konfigürasyonu;
Node1’de yaptığımız işlemleri burada da tekrarlıyoruz.
Şekil 4.48 node2 üzerinde fence device oluşturma işleminden sonra gösterimi
73. Görüldüğü gibi cluster’a dahil herbir node için fence device konfigürasyonlarını
yedekli olarak tamamlamış bulunuyoruz. Konfigürasyonları tamamladıktan sonra
Fence Devices sekmesine tıkladığımızda aşağıdaki şekilde de görüldüğü üzere
pwr01 ve pwr02 adlı fence device’lar clusterdaki node’lar tarafında kullanımda
olduğu görülmektedir.
Şekil 4.49 fence devices konfigürasyonlarından sonra fence device’ların
gösterimi
2) Fence_apc_snmp agent konfigürasyonu
Fence device konfigürasyonunda agent olarak fence_apc_snmp kullanmak için,
APC Power Switch (SNMP interface)üzerinden fence_apc’de yaptığımız
konfigürasyona benzer şekilde işlemleri gerçekleştiriyoruz.
Add tıkladıktan sonra APC Power Switch (SNMP interface)
seçiyoruz.
Name bölümüne apc power switch tanımlamak adına “pwr01”
adını veriyoruz. İkinci apc power switch’e de “pwr02” adını
veriyoruz.
IP Addresss or Hostname bölümüne apc power switch için
belirlediğimiz ip adresini giriyoruz.
Login bölümüne apc power switch’e bağlantı yaptığımız kullanıcı
bilgisini giriyoruz.
Password bölümüne apc power switch’e bağlantı yaptığımız
kullanıcının şifresini giriyoruz.
Submit butonuna tıklıyoruz ve fence_apc agent oluşturma işlemini
tamamlıyoruz.
74. Şekil 4.50 pwr01 adlı apc power switch(SNMP interface) oluşturma işlemi
75. Şekil 4.51 pwr02 adlı apc power switch(SNMP interface) oluşturma işlemi
Network power switch tarafında yedeklilik sağlaması içinpwr01 ve pwr02
adlı iki tane network power switch fence device olarak konfigürasyonunu
aşağıdaki şekil 4.52’deki gibi görebilirsiniz. Aşağıdaki şekilde de görüldüğü
üzere fence_apc_snmp agent’lar clusterdaki node’lar tarafından kullanımda değil.
fence_apc_snmp agent’lar hazır olduğuna göre artık clusterdaki node’larımıza
tanıtmaya geçiyoruz. Cluster’a dahil herbir node için fencing konfigürasyonu
yapılmalıdır.
Şekil 4.52 oluşturulan fence_apc_snmp agent’ların gösterimi
76. Node 1 için fencing konfigürasyonu;
Yukarda anlatığımız şekilde cluster’daki herbir node için fencing
konfigürasyonunu gerçekleştiriyoruz. Aşağıdaki şekilde görüldüğü gibi node1 için
fence method içerisinde yedeklilik sağlanacak şekilde fence device
oluşturulmuştur.
Şekil 4.53 node1 üzerinde fence device oluşturma işleminden sonra gösterimi
Node 2 için fencing konfigürasyonu;
Node1’de yaptığımız işlemleri burada da tekrarlıyoruz ve aşağıdaki şekilde
görüldüğü gibi node2 için fence method içerisinde yedeklilik sağlanacak şekilde
fence device oluşturma işlemlerini gerçekleştiriyoruz.
77. Şekil 4.54 node2 üzerinde fence device oluşturma işleminden sonra gösterimi
Görüldüğü gibi cluster’a dahil herbir node için fence device konfigürasyonlarını
yedekli olarak tamamlamış bulunuyoruz. Konfigürasyonları tamamladıktan sonra
Fence Devices sekmesine tıkladığımızda aşağıdaki şekilde de görüldüğü üzere
pwr01 ve pwr02 adlı fence device’lar clusterdaki node’lar tarafında
kullanımdadır.
Şekil 4.55 fence devices konfigürasyonlarından sonra fence devices’ların
gösterimi
Görüldüğü gibi cluster’a dahil her node için fence agent olarak kullandığımız
fence_apc_snmp agent yedekli olarak tanımlamış bulunuyoruz. Fence device
konfigürasyonlarını tamamladığımıza göre çalışırlılığını kontrol etmek adına
aşağıdaki işlemleri gerçekleştirebilirsiniz.
Yaptığınız konfigürasyonun çalışıp çalışmadığını kontrol etmek adına, bir node’u
78. fence’lemek için “fence_node” komutunu kullanabilirsiniz. “fence_node” komutu
belirtilen node için cluster.conf dosyasından fencing ayarlarını okur ve fencing
konfigürasyonunu çalıştırır. Sonuç olarak log’lara fenced success yada fenced
failed sonucunu döndürür.
# fence_node node1 # cluster’daki node1 makinesini fence’liyoruz. Aynı
şekilde sırasıyla clusterdaki diğer node’larıda fence’leyip durumu
gözlemleyebilirsiniz. Ancak yapacağınız bu işi sırasıyla yapmak gerekmektedir.
Yani node1 makinesini fence’ledikten sonra cluster yapı tamamıyla ayağa
kalkdıktan sonra node2 için fence’leme işlemini gerçekleştirmek gerekmektedir.
# tail - f /var/log/messages # komut ile fence device konfigürasyonunun
çalışırlığını gözlemleyebilirsiniz. Node1 makinesini fence’lediğimizde node2
makinesi üzerinden loglara baktığımızda “node2 fenced[1962]: fence node1
success” şeklinde fencing konfigürasyonunun çalıştığını teyit ediyoruz. Sizlerde
aynı şekilde kontrolerinizi yapmayı unutmayınız.
G. Services Groups Konfigürasyonu
Cluster node’ları arasında aktif node üzerinde çalışması gereken
kaynakları(resources) yönetecek olan servistir. Yani sadece aktif node üzerinde
çalışacak olan cluster servisidir.
Cluster grafik arayüzden Service Groups sekmesini tıklıyoruz ve Add
diyerek cluster servisini oluşturma işlemine başlıyoruz.
Service Name bölümüne cluster servisini belirtecek bir isim
veriyoruz. Aşağıdaki şekilde görüldüğü gibi biz “db_cluster” adı
verdik.
Automatically Start This Service kutucuğunu işaretliyoruz.
Run Exclusive kutucuğunu işaretliyoruz.
Failover Domain bölümünde eğer failover domain oluşturduysanız
buradan seçiyorsunuz. Biz failover domain oluşturduğumuz için
seçiyoruz.
Recovery Policy bölümünde “Relocate” seçiyoruz. Relocate
seçeneği farklı node üzerinde servisi çalıştırmayı denemesini
sağlar.
79. Add Resource butonunu tıklıyoruz ve Resources bölümünde
oluşturduğumuz kaynakları(ip adress, db_data ve mysqld )
ekliyoruz.
Submit butonunu tıklıyoruz ve servis oluşturma işlemini
tamamlıyoruz.
Şekil 4.56 Service Groups oluşturma işlemi
Not: Oluşturduğumuz service groups’a Add Resource butonunu tıklayarak ilk
olarak eklemek istediğimiz resources ekledikten sonra, ikinci resource’u eklemek
istediğimizde Add Resource’ın yanında birde Child Resource butonu gelecektir.
Child resource ile Add Resource arasında hiyerarşi farkı bulunmaktadır. Eğer
belirlediğiniz herhangi bir kaynağın(resource) altına add child resource ile yeni
bir kaynak(resource) tanımlarsanız üstteki kaynak(resource) başlatılmadan diğer
kaynak(resource) başlatılamaz. Bunun yerine oluşturmuş olduğunuz
kaynakları(resource), add resource ile yeni bir kaynak(resource) olarak
tanımlarsanız bu ikisi birbirinden bağımsız olarak çalışırlar. Herbir
kaynak(resoruce) cluster servisi üzerinde başlatılmaya çalışılır.
80. Cluster servisinide oluşturma işlemini tamamladığımıza göre cluster yapısının
çalışırlılığını “clustat” komutunu çalıştırarak kontrol edebiliriz.
Aşağıdaki şekil 4.57’de görüldüğü üzere db_cluster adında servisimiz node1
üzerinde çalışıyor. Cluster servisiniz üzerinde herhangi bir değişiklik yapmak
isterseniz aşağıdaki şekil 4.57’de de görüldüğü üzere db_cluster servisini
durdurabilir, başlatabilir ve yeniden bir cluster serviside oluşturmak istersenizde
silebilirsiniz.
Şekil 4.57 Service Groups oluşturma işleminden sonra cluster servisinin
gösterimi
Cluster servisi hangi node üzerinde aktifse, virtual ip adres’in o node üzerinde
çalıştığını görmek adına “ip addr list eth0” komutunu aşağıdaki şekilde görüldüğü
gibi çalıştırabilirsiniz. Aşağıdaki şekilde görüldüğü gibi “eth0” portuna ait 2 adet
ip adresi bulunmaktadır. Secondary eth0 olarak geçen ip adres bizim cluster
yapının virtual ip adresidir. Buradan da anlaşılacağı üzere aktif node olarak
node1 çalışıyor demektir. Eğer sizin sisteminizde bonding varsa, “eth0” yerine
bonding interface bakmalısınız.
Şekil 4.58 virtual ip adres gösterimi
Cluster yapıda node1 aktif node olarak çalıştığına göre, node1 üzerinde “df -h”
komutunu çalıştırdığımda mysql veritabanı verilerinin yazılması için
oluşturduğumuz veri diskine mount olduğunu aşağıdaki şekil 4.59’daki gibi
görüyor olmanız gerekiyor.
81. Şekil 4.59 df -h komutunun çıktısı
Gerekli işlemleri yaptıktan sonra, bütün cluster servislerinin node’lar yeniden
başlatılsada her zaman açık olması için aşağıdaki komutları çalıştırıyoruz.
# chkconfig --list cman
# chkconfig cman on
# chkconfig --list clvmd
# chkconfig clvmd on #Eğer cluster volume’ler oluşturulurken clvm
kullandıysanız gereklidir.
# chkconfig --list gfs2
# chkconfig gfs2 on #Eğer dosya sistemi olarak RedHat GFS2
kullanıldıysa gereklidir.
# chkconfig modclusterd on
# chkconfig --list modclusterd
# chkconfig --list rgmanager
# chkconfig rgmanager on
Bu komutları cluster’daki bütün node’lar üzerinde çalıştırdıktan sonra artık
makineler reboot olsada cluster servisleri her zaman açık olacaktır. Ayrıca cluster
servislerini komutsatırındanda herhangi bir cluster servisinin çalışırlılığını
kontrol etmek için aşağıda verildiği gibi kullanabilirsiniz.
# service rgmanager status/start/restart/stop
82. H. Cluster Konfigürasyon Dosyasını İnceleme
Cluster konfigürasyon çalışmalarını tamamladık. Şimdi yapılan cluster
konfigürasyonuna göz gezdirelim ve farklı açılardan cluster konfigürasyonunu
değiştirmek adına neler yapılabilir ve dikkat edilmesi gereken durumlar neler
olabilir örneklerle inceleyelim.
# cat /etc/cluster/cluster.conf #herhangi bir node üzerinde komutunu
çalıştırdığımızda cluster konfigürasyonu aşağıdaki gibi ekrana gelecektir.
[root@node1 ~]# cat /etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster config_version="26" name="mycluster">
<clusternodes>
<clusternode name="node1" nodeid="1">
<fence>
<method name="Method_1">
<device name="pwr01" option="off" port="1"/>
<device name="pwr02" option="off" port="1"/>
<device name="pwr01" option="on" port="1"/>
<device name="pwr02" option="on" port="1"/>
</method>
</fence>
</clusternode>
<clusternode name="node2" nodeid="2">
<fence>
<method name="Method_1">
<device name="pwr01" option="off" port="2"/>
<device name="pwr02" option="off" port="2"/>
<device name="pwr01" option="on" port="2"/>
84. </service>
</rm>
<fencedevices>
<fencedevice agent="fence_apc_snmp" ipaddr="192.168.128.100"
login="apc" name="pwr01" passwd="apc"/>
<fencedevice agent="fence_apc_snmp" ipaddr="192.168.128.101"
login="apc" name="pwr02" passwd="apc"/>
</fencedevices>
</cluster>
[root@node1 ~]#
Konfigürasyona baştan sona doğru göz gezdirdiğimizde, grafik arayüzden
yaptığımız cluster konfigürasyonlarının buraya xml formatında yazıldığını
görüyoruz. Cluster konfigürasyonu ile ilgili değişiklikler yapmak istediğimizde
buradan “vi” editörü ile yapabiliriz. Ancak buradan yapacağımız düzenlemelerde
herhangi bir hata yaptığımızda cluster konfigürasyonu çalışmayacaktır. Burada
yapılabilecek hatalara örnek olması için aşağıdaki konfigürasyon örneklerini
inceleye bilirsiniz.
Cluster konfigürasyon dosyasının başında belirlenmiş olan cluster
config_version="26" değerinin ne olduğu akıllara gelebilir. Bir cluster
konfigürasyon dosyası, cluster konfigürasyon versiyon değeri içerir. Bu değere ilk
defa cluster konfigürasyon dosyası oluşturduğunuz zaman default olarak “1” atanır
ve siz cluster konfigürasyonunda yaptığınız her değişiklik sonrası bu değer
otomatik olarak “1” artar. Bizim yaptığımız konfigürasyonda bu değer 26
olduğuna göre, cluster konfigürasyonu süresince bu kadar değişiklik yaptığımızın
göstergesidir. Bu değerin kaç olduğunu aşağıdaki komutu çalıştırarakta
görebilirsiniz.
Not: cluster config verisoncluster’daki herbir node üzerinde aynı değerde
olması gerekir aksi takdirde cluster konfigürasyon dosyaları arasında farklılıklar
olduğu anlaşılır ve cluster yapısında hatalarla karşılaşabilirsiniz.
# ccs -h node1 --getversion # cluster konfigürasyon versiyon değerinin
85. kaç olduğunu gösterir.
# ccs -h node1 --incversion # bu komut cluster konfigürasyon versiyon
değerinin 1 arttırılmasını sağlar.
Örnek-1: cluster.conf örnek konfigürasyon: XML hatası
<cluster nam ="mycluster" config_version="1">
<clusternodes>
<clusternode name="node-01" nodeid="1">
<fence>
</fence>
</clusternode>
<clusternode name="node-02" nodeid="2">
<fence>
</fence>
</clusternode>
<clusternode name="node-03" nodeid="3">
<fence>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
</fencedevices>
<rm >
</rm >
<cluster> <----------------GEÇERSİZ
Bu örnekte, konfigürasyonun son satırında geçersiz diyerek belirttiğimiz yere
86. dikkatlice baktığımızda </cluster> şeklinde yazılmasını gerekiyorken <cluster>
yazılmıştır. Yani sadece bir “/” eksikliği cluster’ın çalışmamasına sebep
olacaktır.
Örnek-2: cluster.conf dosyasının sadece resource bölümüne örnek
konfigürasyon: Geçersiz seçenek
<resources>
<ip address="192.168.128.13" sleeptime="10"/>
<fs device="/dev/sdg1" force_fsck="on" force_unmount="on"
fsid="28092" fstype="ext4" mountpoint="/var/lib/mysql" name="db_data"
quick_status="on" self_fence="on"/>
<script file="/etc/init.d/mysqld" name="mysqld"/>
</resources>
Bu örnekte, sarı renkle belirttiğimiz yere dikkatlice baktığımızda "/dev/sdb1"
yazılması gerekiyorken "/dev/sdg1" yazılmıştır. Yani cluster konfigürasyonuna
mount ettğimiz disk yanlış tanımlanmış.
Örnek-3: cluster.conf örnek konfigürasyon: Geçersiz değer girilmesi
<cluster nam ="mycluster" config_version="1">
<clusternodes>
<clusternode name="node-01" nodeid="1">
<fence>
</fence>
</clusternode>
<clusternode name="node-02" nodeid="-2"> <----------------
GEÇERSİZ
<fence>
</fence>
</clusternode>
<clusternode name="node-03" nodeid="3">
87. <fence>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
</fencedevices>
<rm >
</rm >
</cluster>
Bu örnekte, sarı renkle belirttiğimiz yere dikkatlice baktığımızda clusternode daki
node-02 için nodeid xml için geçersiz bir değer içerir. Bu değer negatif bir değer
“-2” dir. Bunun yerine pozitif bir değer “2” girilmelidir. Yani nodeid değerleri
pozitif olmalıdır.
Sonuç olarakcluster.conf dosyasında yapacağınız düzenlenmelerde ve
değişikliklerde, yaptığınız işlemlerden sonra aşağıdaki komutu çalıştırarak
configürasyon dosyasında hata yapıp yapmadığınızı görebilirsiniz. Aşağıdaki
şekilde görüldüğü üzere bizim yaptığımız konfigürasyonda herhangi bir hata
bulunmadığını gösteren bir sonuç alıyoruz.
# ccs_config_validate
Şekil 4.60 cluster.conf dosya geçerliliğinin kontrol edilmesi
I. Grafik Arayüzden Varolan Cluster’a Node Ekleme-Kaldırma
Var olan cluster’ımıza grafik arayüzden kolay bir şekilde yeni bir node ekleyebilir
veya cluster node’lardan istediğimizi cluster’dan çıkarabiliriz. Cluster
servislerini ve node’ları etkilemeksizin bu işlemleri kolayca yapabilirsiniz ancak
hata yapma işlemine karşın dikkatli bir şekilde işlemleri gerçekleştirmekte fayda
vardır.
88. Varolan cluster’a yeni bir node ekleme için;
Anasayfada sol taraftaki menüden Manage Clusters tıklıyoruz.
Birden fazla cluster yapısı varsa, hangi cluster’a node ekleyeceksek
onu seçiyoruz.
Add tıklıyoruz ve Add Nodes to Cluster ekrana geliyor.
Node isimini ve ricci şifresini giriyoruz.
Add Clustertıklıyoruz ve cluster’a yeni bir node ekleme işlemini
aşağıdaki şekilde görüldüğü gibi tamamlıyoruz.
Şekil 4.61 Cluster’a node ekleme işlemi
Not: Node ekleme işlemini yaptıktan sonra, fence device konfigürasyonlarını yeni
eklediğimiz node’a tanıtmayı unutmamalısınız.
Varolan cluster’dan herhangi bir node kaldırma işlemi;
Anasayfada sol taraftaki menüden Manage Clusters tıklıyoruz.
Cluster’dan kaldırmak istediğimiz node veya node’ları seçiyoruz.
Leave Clustertıklıyoruz ve cluster’dan node çıkarma işlemini
aşağıdaki şekilde görüldüğü gibi tamamlıyoruz.
89. Şekil 4.62 cluster’dan node çıkarma işleminden sonraki gösterimi
Node’u cluster’dan çıkardıktan sonra, yanındaki kutucu işaretleyipDelete
dediğimizde clusterdan tamamen kaldırma işlemini gerçekleştirmiş oluyoruz.
Grafik arayüz üzerinden genel olarak cluster yapısından bahsettik. Bunların
dışından konfigürasyonda ince ayarlar gerekmediği sürece cluster
konfigürasyonunu ve yönetimini grafik arayüzden yapabileceğinizi gösterdik.
Cluster’daki node’ların yeniden başlatılması (reboot), cluster’a yeni bir node
eklenmesi (Add) ve cluster’a dahil edilmesi (Join Cluster), cluster’daki node’un
silinmesi (Delete) gibi işlemlerden cluster konfigürasyonunda yapmak istediğiniz
değişikliklere kadar (Fence Devices, Failover Domains, Resources, Service
Groups, Configure) gerekli gördüğünüz işlemleri yapabilirsiniz.
Cluster konfigürasyon ve yönetim çalışmalarını grafik arayüzden
yaptığımıza göre, komut satırınada alışmak adına ki Linux/Unix türü işletim
sistemlerinin yönetimini yapıyorsanız komut satırından kaçamazsınız. Ayrıca
bulunduğunuz ortamda grafik arayüz bulunmayabilir yada uzaktan sisteme
bağlanmış ve grafik arayüzden yoksun olabilirsiniz bunlarıda gözönünde
bulundurduğumuzda komut satırı vazgeçilmez oluyor. Artık bölüm 5’te ccs
komutuyla komut satırından cluster konfigürasyon ve yönetimine geçebiliriz. Şunu
da belirtmek isterim ki komut satırına alıştıktan sonra, komut satırının daha kolay
ve eğlenceli olduğunu farkedeceksiniz.
90. BÖLÜM – 5
Cluster Konfigürasyonu &Yönetimi (Komut Satırı)
Cluster konfigürasyonunu ve yönetimini bir önceki bölümde grafik
arayüzden anlatmıştık. Şimdi de komut satırından nasıl yapacağımızı görüyor
olacağız. Cluster yapıyı ccs komutu ile oluşturabilir, değiştirebilir ve yönetimini
sağlayabilirsiniz. ccs komutunu kullanarak lokalden yada uzaktan cluster
konfigürasyon dosyasında yada cluster servisleri üzerinde yapmak istediklerinizi
gerçekleştirebilirsiniz.
Cluster konfigürasyonunu ve yönetimini bölüm-4’te detaylı bir şekilde
anlattığımız için burada detaydan daha çok komut satırından, ccs komutuyla cluster
konfigürasyonlarını yapabileceğimize ve cluster yönetimini sağlayabileceğimize
değineceğiz.
Bu bölümde cluster konfigürasyonu ve yönetimini aşağıdaki gibi ele alıyor
olacağız;
Cluster Oluşturma(Create)
Cluster’a Node Ekleme/Kaldırma
Fence Devices
Failover Domains
Resources
Service Groups
A. Cluster Oluşturma
Aşağıdaki komutu çalıştırdığınızda cluster’a dahil etmek istediğiniz node’lardan
birisinin üzerinde cluster konfigürasyon dosyasını oluşturmuya başlıyor
olacaksınız.
-h parametresi node isminin girilmesi için gerekli parametredir.
--createcluster parametresi cluster isminin girilmesi için gerekli parametredir.
# ccs -h node1 --createcluster mycluster
91. Şekil 5.1 Node1 üzerinde mycluster adında cluster oluşturma işlemi
Not: Eğer cluster oluşturmak istediğiniz node üzerinde cluster.conf dosyası
varsa, şekil 5.1’de gösterildiği gibi komutu çalıştırdığınızda var olan dosya yerine
yeni oluşturduğunuz cluster konfigürasyon dosyası geçecektir. Cluster
konfigürasyon dosyasının üzerine yazmak için “–i” parametresi gerekebilir.
Şekil 5.1 de çalıştırılan komutu yorumlarsak; node1 üzerinde mycluster adlı bir
konfigürasyon dosyası oluşturulmuştur. Bu işlemden sonra cat komutuyla,
oluşturulan konfigürasyon dosyasını şekil 5.2’deki gibi görebilirsiniz.
# cat /etc/cluster/cluster.conf
Şekil 5.2 cat komutuyla yeni oluşturulan cluster.conf dosyasının gösterimi
Not: Daha önceki bölümlerde ricci servisini çalıştırma ve şifre verme işlemini
yapmıştık. Bundan dolayı burada tekrardan değinmiyoruz. Ancak ricci servisinin
çalışması önemli olduğundan durumunu gözlemleyip geçiyoruz.
Ricci servisi, clusterda node’lar üzerindeki cluster konfigürasyon dosyalarını
dağıtmak ve oluşturmak için herbir node üzerinde çalıştırılması gereklidir.
# /etc/init.d/ricci status
Şekil 5.3 Node1 üzerinde ricci servisinin durumu
Şekil 5.4 Node2 üzerinde ricci servisinin durumu
92. B. Cluster’a Node Ekleme/Kaldırma
mycluster adlı cluster konfigürasyon dosyasını oluşturduğumuza göre şimdi,
cluster’a dahil etmek istediğimiz node’ları ekleme işlemine geçebiliriz. Aşağıdaki
komutları çalıştırdığımızda node1 üzerinde oluşturmaya devam ettiğimiz cluster
konfigürasyon dosyasına node1 ve node2 adında makineleri eklemiş olacağız.
# ccs -h node1 --addnode node1
# ccs -h node1 --addnode node2
Şekil 5.5 Cluster’a node ekleme işlemi
Cluster’a dahil edilmiş node’ların listesini aşağıdaki komutu çalıştırdığımızda
görebiliriz. şekil 5.6’da görüldüğü gibi node1 ve node2 makineleri cluster’a
eklenmiştir. Ayrıca cluster’a eklenmiş node’ları şekil 5.7’deki gibi cluster.conf
dosyasında da görebiliriz.
# ccs -h node1 --lsnodes
Şekil 5.6 Cluster’a eklenmiş node’ların listesi
Şekil 5.7 Node ekleme işleminden sonra cluster.conf dosyasının gösterimi