У нас є додаток, який працює на декількох (5 або більше і буде рости) вікнах. Апаратне забезпечення однакове у всіх машинах, і в ідеалі це було б також програмне забезпечення. Я керував ними вручну до цих пір, і більше не хочу (статичні IP-адреси, відключення всіх необхідних сервісів, установка необхідних пакетів ...). Чи може хтось збалансувати плюси і мінуси наступних варіантів, або запропонувати щось більш розумне?

1: Індивідуально встановіть центоси на всі поля і керуйте конфігураціями за допомогою шеф-кухаря / cfengine / маріонетки. Це було б добре, оскільки я хотів, щоб виправдати навчитися користуватися одним із застосунків, але я не знаю, чи це насправді найкраще рішення.

2: Зробіть одну коробку ідеальною і зображте її. Подавайте зображення через PXE і коли я хочу внести зміни, я можу просто перезавантажити поля з нового зображення. Як хлопці кластера зазвичай обробляють такі речі, як мак-адреси у файлах / etc / sysconfig / network-scriptpts / ifcfg *? Ми також використовуємо infiniband, і він також відмовляється починати, якщо hwaddr помиляється. Чи можна їх правильно створити під час завантаження?

Я схиляюся до рішення PXE, але я думаю, що моніторинг з муніном або нагіосом буде дещо складніше з цим. У когось є досвід подібного типу проблем?

Всі сервери мають в них SSD, вони швидкі та потужні.

Спасибі, матовий.

Ваш кластер звучить більше як кластер HPC, ніж такий, як OLTP, як у мене, але я думаю, що налаштування, яке я використовую, буде працювати і для вас. Я називаю це "mpdehaan trifecta", тому що це іскрість хлопця, який написав або керує трьома залученими інструментами.

1.) Бобер для забезпечення базового будівництва. Cobbler - це проект, який має на меті перетин вашої системи kickstart, pxe, yum-repo, dhcp, dns тощо. Це, безумовно, найпростіший спосіб встановити та запустити налаштування швидкого старту, і ви можете перерости в інші функції за потребою.

2.) Лялька для управління конфігурацією. В ідеалі ваш швець побудовані господарі дуже Barebones конфіги , які знають тільки досить , щоб подзвонити додому , щоб ваш ляльковий сервер при запуску. Потім лялечка застосує ваші налаштування конфігурації та буде постійно підтримувати їх у вашому оточенні.

3.) Функція для тимчасових команд для декількох машин паралельно. Наприклад, "розгорнути новий svn замовлення коду та перезапустити apache". Досить просто використовувати функцію для виклику тієї ж команди bash на групі серверів, як кластер-ssh. Якщо ви дійсно хочете ввійти в нього, ви можете написати свої власні модулі для цього за допомогою простого пітона.

Усі три інструменти мають хороші вікі та активні канали irc для довідки про freenode.

Огляд

У чомусь у вас тут два питання ..

• Як створити та підтримувати стандартні сервери?
• Як я можу підтримувати стандартну конфігурацію та вносити зміни пізніше?

Я розділив свою відповідь нижче, торкаючись цих двох речей окремо, але вони дуже тісно пов'язані. Тут я звертаюсь до технологічних рішень, а не до жодної з найкращих пов’язаних практик, таких як контроль змін.

Якщо це не стосується сфери вашого запитання, уточнюйте, і я буду радий детально розглянути. Це необхідний фундамент, який є критичним для добре розвиненої технологічної інфраструктури.

Побудова серверів

Мені не подобаються образи у світі UNIX; це більше підхід до стилю Windows. Навіть деякі люди з Windows, як здається, переорієнтуються на сценарії для стандартних збірок.

Супутник, здається, стає дещо популярним у світі RHEL. Spacewalk - аналог з відкритим кодом. Для використання цього ви, безумовно, повинні купувати підхід RHEL повністю. Це служить як побудовою сервера, так і керуванням конфігурацією.

В ідеалі, ви хочете встановити локальні дзеркала та сховища на файловому сервері для всього необхідного програмного забезпечення.

По-перше, скористайтеся автоматизацією побудови дистрибуції, наприклад, Kickstart в RHEL / CentOS. Kickstart буде базовою лінією з варіаціями, залежно від ваших потреб. Створення Kickstart може бути ініційовано з PXE-сервера.

Для більш досконалої частини збірки та всього, що не підходить для файлу Kickstart, ви можете написати власні спеціальні сценарії. Однак ви можете виявити, що ляльковий або cfengine добре працює для вас замість користувацьких сценаріїв. Я встановив, що спеціальні сценарії є найбільш гнучкими і не обмежуються будь-яким єдиним підходом.

Якщо ви вирішили написати власні сценарії, я рекомендую основний сценарій для універсальної конфігурації. Це буде конфігурація безпеки, загартовування та все, що стосується всіх збірок. Потім фінальний сценарій для завершення ролі сервера. Наприклад, веб-сервер або сервер баз даних.

Підтримання стандартів

Те, що ви описуєте, також підпадає під збереження конфігурацій. Стандарти складання, оновлення програмного забезпечення та інші речі пов’язані із складаннями, але багато в чому роздільні.

Якщо ви вирішили покластися на системні пакети, на відміну від створення власних побудованих джерел для ваших найважливіших ролей сервера, багато чого можна підтримувати за допомогою нативних системних утиліт. Це може бути настільки ж простим сценарієм, щоб запустити forцикл проти списку вашого сервера та запустити a yum -y update package.

Для управління конфігурацією тут грають лялькові, cfengine та інші утиліти управління конфігурацією . Це дуже корисні утиліти та забезпечують необхідну основу без написання власних сценаріїв з нуля.

Коли ви оновлюєте свої конфігураційні стандарти для своїх серверів, важливо повернути це в стандартні версії сервера.

Нещодавно я закінчив великий проект із впровадження централізованої системи управління побудовою / забезпеченням та конфігурацією на $ WORK. Ми працюємо CentOS.

Мій дизайн, який мені справді подобається, дає нам практично один клік (ну, одна веб-сторінка із графічним інтерфейсом), використовуючи деякі спеціальні сценарії PHP, щоб зв’язати все разом за допомогою простого, але ефективного веб-інтерфейсу.

Загальна теорія:

1. Зробіть усі встановлення з одного, уніфікованого, мінімалістичного файлу KickStart (ну добре, один для x86 та один для x86-64, але все-таки практично однакові файли з мінімальним вибором пакету).
2. KickStat після встановлення сценарію завантаження ляльок.
3. Лялька застосовує всю конфігурацію вузла / хоста, установку пакету тощо.

Я погоджуюся, що зображення не є Unix-y способом робити речі ... вони дійсно більше підходять до світу Windows, де сценарій / автоматизована установка та конфігурація не так проста.

Ви можете замінити Маріонетку будь-якою іншою системою управління конфігурацією, яка відповідає законопроекту, але мені здається, що декларативний характер Маріонетки та її концепція конвергенції.

Ця система дає ряд переваг:

• Лялька обробляє все, що минуло загальну установку бази, тому всі необхідні пакети та конфігурація знаходяться в одному місці.
• Лялечні маніфести служать додатковим джерелом документації низького рівня.
• Поки ви дотримуєтесь Puppet (тобто не вносите зміни локальних конфігурацій або не об'єднуйте їх назад у Puppet), тривіально створити дублікат машини.
• Оскільки всі хости побудовані із загальної бази, ви можете попередньо встановити апаратне забезпечення або VM з базовим набором (KickStart) пакетом, а потім перетворити їх у функціональні вузли, просто додавши класи за потребою.
• Лялька дозволяє "тегувати" хостів для виробництва чи розробки, тому неймовірно просто створити розробку / тестування копії хоста, оновити пакети або внести зміни конфігурації за необхідності, протестувати, а потім об'єднати назад у виробництво.

Якщо ви спускаєтесь по маршруту pxe, не забудьте переглянути

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

Gpxe надасть вам більше гнучкості під час завантаження цілей. Завантажити лезо Aoe досить просто, і немає нічого подібного до завантаження ядра з віддаленого http-сервера !!!!!!!!!! :-).

Який час роботи сервера потрібен?

Створити ідеальний образ неможливо, оскільки вам завжди потрібно буде застосовувати патчі безпеки та оновлення програмного забезпечення. Якщо вони підключені до Інтернету, ви не можете просто ігнорувати виправлення.

З боку pxe у вас є кілька варіантів, залежно від вводу / виводу файлу кластеру. Або просто завантажте ядро ​​і віддалено встановіть диск через aoe або iscsi.

Ви також можете зробити кілька дуже розумних речей з копією на записаних зображеннях. Він чудово підходить для оновлення та скасування будь-яких змін, які можуть бути проблематичними.

Я також мав успіх у використанні nfs root, використанні кластерного рішення nfs. Ви можете вказати різні файли, які потрібно обслуговувати, залежно від їх клієнтських адрес.

Знову ж таки, ви повинні перевірити, чи не подобається вашій програмі запуску nfs. Він не підходить для кожного навантаження.

кластерний nfs sever може містити 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

Таким чином, кожен клієнт посилається на один і той же файл, але йому подають файл, відповідний клієнту. Це дуже вражаючі речі, однак це не просто!

Все це дасть вам швидший час запуску, якщо централізувати файлову систему на мережевому сховищі. Зображення операційної системи через мережу на віддалений диск вимагає часу !!!!

Якщо ви використовуєте будь-яке з цих рішень, переконайтеся, що у вас добре розроблений мережевий рівень та стійкий до несправностей, і що ваш nfs / SAN-сервер добре розроблений і захищений!

Якщо втратити з'єднання, ваш NFS / SAN буде поганим для здоров'я сервера. :-(

Зробити деякі сценарії для tftp / pxe досить просто, щоб керувати процесом завантаження.

Якби я більше знав, що ти насправді намагаєшся скупчити, я, можливо, міг би придумати рішення, яке підходило б тобі більше.