Mengelola aplikasi di beberapa server, atau PXE vs cfEngine / Chef / Puppet


15

Kami memiliki aplikasi yang berjalan di beberapa (5 atau lebih dan akan tumbuh) kotak. Perangkat kerasnya identik di semua mesin, dan idealnya perangkat lunaknya juga. Saya telah mengelola mereka dengan tangan sampai sekarang, dan tidak mau lagi (alamat ip statis, menonaktifkan semua layanan yang diperlukan, menginstal paket yang diperlukan ...). Adakah yang bisa menyeimbangkan pro dan kontra dari opsi berikut, atau menyarankan sesuatu yang lebih cerdas?

1: Secara individual instal centos di semua kotak dan kelola konfigurasi dengan chef / cfengine / boneka. Ini akan bagus, karena saya ingin alasan untuk belajar menggunakan salah satu aplikasi, tetapi saya tidak tahu apakah ini sebenarnya solusi terbaik.

2: Buat satu kotak sempurna dan gambar itu. Sajikan gambar melalui PXE dan kapan pun saya ingin membuat modifikasi, saya bisa mem-boot ulang kotak dari gambar baru. Bagaimana orang-orang cluster biasanya menangani hal-hal seperti memiliki alamat mac di file / etc / sysconfig / network-scripts / ifcfg *? Kami menggunakan infiniband juga, dan juga menolak untuk memulai jika hwaddr salah. Apakah ini dapat dihasilkan dengan benar saat boot?

Saya condong ke arah solusi PXE, tapi saya pikir pemantauan dengan munin atau nagios akan sedikit lebih rumit dengan ini. Adakah yang punya pengalaman dengan masalah seperti ini?

Semua server memiliki SSD di dalamnya dan cepat dan kuat.

Terima kasih, Matt.

Jawaban:


12

Cluster Anda lebih mirip kluster HPC daripada OLTP seperti kluster milik saya, tapi saya pikir setup yang saya gunakan juga akan bekerja untuk Anda. Saya menyebutnya "mpdehaan trifecta" karena itulah ircnick dari orang yang menulis atau mengelola tiga alat yang terlibat.

1.) Tukang sepatu untuk penyediaan dasar-bangunan. Cobbler adalah proyek yang bertujuan untuk memotong sistem kickstart, pxe, yum-repo, dhcp, dns, dll Anda. Sejauh ini cara termudah untuk menyiapkan dan menjalankan kickstart, dan Anda dapat tumbuh menjadi fitur-fitur lain yang diperlukan.

2.) Wayang untuk manajemen konfigurasi. Idealnya tukang dibangun Anda host sangat barebones konfigurasi yang tahu hanya cukup untuk telepon rumah ke server boneka Anda pada startup. Boneka kemudian akan menerapkan pengaturan konfigurasi Anda dan membuatnya konsisten di lingkungan Anda untuk selamanya.

3.) Berfungsi untuk perintah ad-hoc ke beberapa mesin secara paralel. Misalnya "menyebarkan checkout svn baru dari kode dan restart apache". Cukup mudah untuk menggunakan func untuk memanggil perintah bash yang sama pada sekelompok server seperti halnya cluster-ssh. Jika Anda benar-benar ingin memasukinya, Anda dapat menulis modul sendiri untuknya dengan beberapa python yang sangat sederhana.

Ketiga alat ini memiliki saluran irc wiki yang baik dan aktif untuk bantuan pada freenode.


Saya pikir ini adalah solusi yang akan saya gunakan. Saya akan mencobanya dan memberi tahu Anda semua. Saya mungkin akan menulis blog prosesnya juga. Terima kasih!
matt

5

Gambaran

Dalam beberapa hal, Anda memiliki dua pertanyaan di sini ..

  • Bagaimana cara saya membangun dan memelihara server standar?
  • Bagaimana cara mempertahankan konfigurasi standar dan membuat perubahan nanti?

Saya telah membagi jawaban saya di bawah ini untuk membahas dua hal itu secara terpisah tetapi mereka sangat terkait. Saya membahas solusi teknologi di sini dan bukan salah satu praktik terbaik yang terkait, seperti kontrol perubahan.

Jika ini tidak mencakup ruang lingkup pertanyaan Anda, mohon klarifikasi dan saya akan dengan senang hati menjelaskan. Ini adalah fondasi yang penting, yang sangat penting untuk infrastruktur teknologi yang dikelola dengan baik.

Membangun Server

Saya tidak suka gambar di dunia UNIX; itu lebih merupakan pendekatan gaya Windows. Bahkan beberapa orang Windows tampaknya memfokuskan kembali pada skrip untuk pembuatan standar sekarang.

Satelit tampaknya semakin populer di dunia RHEL. Spacewalk adalah mitra Open Source. Anda pasti harus membeli sepenuhnya ke pendekatan RHEL untuk menggunakan ini. Ini berfungsi sebagai bangunan server dan manajemen konfigurasi.

Idealnya, Anda ingin membuat mirror dan repositori lokal pada server file untuk semua perangkat lunak yang diperlukan.

Pertama, manfaatkan otomasi build distribusi Anda, seperti Kickstart di RHEL / CentOS. Kickstart akan menjadi baseline dengan variasi, tergantung pada kebutuhan Anda. Build Kickstart dapat dimulai dari server PXE.

Untuk bagian yang lebih maju dari bangunan dan apa pun yang tidak cocok untuk file Kickstart, Anda bisa menulis skrip khusus Anda sendiri. Namun, Anda mungkin menemukan boneka atau cfengine berfungsi dengan baik untuk Anda alih-alih skrip khusus. Saya telah menemukan skrip khusus sebagai yang paling fleksibel dan tidak terbatas pada pendekatan tunggal.

Jika Anda memilih untuk menulis skrip Anda sendiri, saya sarankan skrip inti untuk konfigurasi universal. Ini akan menjadi konfigurasi keamanan, pengerasan, dan apa pun yang berlaku untuk semua build. Kemudian skrip terakhir untuk menyelesaikan peran server. Misalnya, server web atau server basis data.



Mempertahankan Standar

Apa yang Anda uraikan juga berada dalam pemeliharaan konfigurasi. Standar pembangunan, pembaruan perangkat lunak, dan hal-hal lain terkait dengan pembangunan tetapi dalam banyak hal terpisah.

Jika Anda memilih untuk mengandalkan paket sistem daripada membuat build berbasis sumber Anda sendiri untuk peran server Anda yang paling penting, banyak yang dapat dipertahankan dengan utilitas sistem asli. Ini bisa berupa skrip sederhana untuk menjalankan forperulangan terhadap daftar server Anda dan menjalankan a yum -y update package.

Untuk manajemen konfigurasi, ini adalah di mana boneka, cfengine, dan utilitas manajemen konfigurasi lainnya ikut berperan. Ini adalah utilitas yang sangat berguna dan menyediakan fondasi yang diperlukan tanpa menulis skrip Anda sendiri dari awal.

Ketika Anda memperbarui standar konfigurasi untuk server Anda, penting untuk mengisi ulang ini ke server standar Anda.


0

Saya baru-baru ini menyelesaikan sebuah proyek besar untuk meluncurkan sistem manajemen konfigurasi / bangun yang terpusat dengan $ WORK. Kami menjalankan CentOS.

Desain saya, yang kebetulan saya sukai, memberi kami proses pembuatan hampir satu klik (yah, satu halaman web GUI), menggunakan beberapa skrip PHP khusus untuk menyatukan semuanya melalui UI web yang sederhana namun efektif.

Teori umum adalah:

  1. Lakukan semua pemasangan dari satu file KickStart tunggal, terpadu, minimalis (well, OK, satu untuk x86 dan satu untuk x86-64, tapi tetap saja, file yang hampir identik dengan pilihan paket minimal).
  2. KickStat postinstall script bootstraps Puppet.
  3. Wayang menerapkan semua konfigurasi node / host-spesifik, instalasi paket, dll.

Saya setuju bahwa gambar bukan cara Unix-y dalam melakukan sesuatu ... mereka benar-benar lebih cocok untuk dunia Windows di mana instalasi dan konfigurasi yang dibuat secara skrip / otomatis tidak sesederhana itu.

Anda dapat mengganti Wayang dengan sistem manajemen konfigurasi lain yang sesuai dengan tagihan, tetapi saya menyukai sifat deklaratif Wayang dan konsep konvergensi.

Sistem ini menghasilkan sejumlah manfaat:

  • Wayang menangani semuanya melewati instalasi basis generik, sehingga semua paket dan konfigurasi yang diperlukan ada di satu tempat.
  • Manifes wayang berfungsi sebagai sumber tambahan untuk dokumentasi tingkat rendah.
  • Selama Anda tetap menggunakan Wayang (yaitu tidak membuat perubahan konfigurasi lokal, atau menggabungkannya kembali ke Wayang) itu sepele untuk membuat duplikat mesin.
  • Karena semua host dibangun dari basis umum, Anda dapat melakukan pra-instal perangkat keras atau VM dengan paket dasar (KickStart) dan kemudian mengubahnya menjadi node fungsional hanya dengan menambahkan kelas yang diperlukan.
  • Wayang memungkinkan host "menandai" untuk produksi atau pengembangan, jadi sangat mudah untuk membangun salinan pengembangan / pengujian dari sebuah host, mengupgrade paket atau membuat perubahan konfigurasi sesuai kebutuhan, menguji, dan kemudian bergabung kembali ke produksi.

0

Jika Anda menuruni rute pxe, pastikan untuk melihatnya

http://etherboot.org/wiki/index.php

Gpxe akan memberi Anda lebih banyak fleksibilitas dengan target boot. Sangat mudah untuk mem-boot blade aoe dan tidak ada yang seperti mem-boot kernel dari server http jarak jauh !!!!!!!!!! :-).

Server berapa kali yang Anda butuhkan?

Tidak mungkin untuk membuat gambar yang sempurna, karena Anda akan selalu perlu menerapkan patch keamanan dan peningkatan perangkat lunak. Jika mereka menghadapi internet, Anda tidak bisa mengabaikan tambalan.

Di sisi pxe, Anda punya beberapa opsi, tergantung pada file I / O Anda. Baik mem-boot kernel dan me-mount disk dari jarak jauh di atas aoe atau iscsi.

Anda juga dapat melakukan beberapa hal yang sangat pintar dengan menyalin gambar tulis. Ini bagus untuk peningkatan dan mengembalikan segala perubahan yang mungkin bermasalah.

Saya juga telah sukses menggunakan nfs root, menggunakan solusi nfs yang dikelompokkan. Anda dapat menentukan file yang berbeda untuk dilayani tergantung pada alamat klien mereka.

Sekali lagi, Anda harus memeriksa apakah aplikasi Anda suka menjalankan nfs. Ini tidak cocok untuk setiap beban kerja.

nfs cluster berkerumun dapat berisi 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

jadi, setiap klien mereferensikan file yang sama, tetapi dilayani file yang relevan untuk klien. Ini hal yang cukup mengesankan, namun tidak sederhana!

Semua ini akan memberi Anda waktu peluncuran lebih cepat jika Anda memusatkan sistem file pada penyimpanan jaringan. Pencitraan sistem operasi melalui jaringan ke disk jarak jauh membutuhkan waktu !!!!

Jika Anda menggunakan salah satu dari solusi ini, pastikan Anda memiliki lapisan jaringan yang dirancang dengan baik dan toleran terhadap kesalahan dan bahwa server nfs / SAN Anda dirancang dengan baik + aman!

Kehilangan koneksi NFS / SAN Anda akan berdampak buruk bagi kesehatan server. :-(

Sangat mudah untuk membuat beberapa skrip untuk tftp / pxe untuk mengontrol proses boot.

Jika saya tahu lebih banyak tentang apa yang sebenarnya Anda coba lakukan, saya mungkin bisa memikirkan solusi yang lebih cocok untuk Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.