Настройка конфигурации программного обеспечения компьютерных систем

Обновлено: 05.07.2024

В диспетчере конфигурации базовые параметры используются для определения конфигурации продукта или системы, установленной в определенный момент времени. Базовые параметры конфигурации в Диспетчер конфигурации содержат определенный набор желаемых конфигураций, которые оцениваются для соответствия требованиям группы.

Базовые параметры конфигурации

Базовые параметры конфигурации содержат один или несколько элементов конфигурации со связанными правилами, и они назначены компьютерам через коллекции вместе с расписанием оценки соответствия требованиям.

Хотя базовые параметры конфигурации можно назначить набору пользователей, базовые параметры конфигурации оцениваются только компьютерами в коллекции.

Вы можете создать собственные базовые параметры конфигурации с консоли Configuration Manager и импортировать базовые параметры конфигурации из следующих источников:

Базовый базовый базовый параметр конфигурации "Лучшие практики" от Microsoft или других поставщиков

Настраиваемые базовые параметры конфигурации из вашей организации, но внешние для Configuration Manager

Другой сайт Диспетчер конфигурации

При импорте базовых конфигураций, если они изначально не были созданы на том же сайте Configuration Manager, вы не можете напрямую изменять их в консоли Configuration Manager. Если необходимо уточнить элементы конфигурации для удовлетворения бизнес-требований, рекомендуемый путь:

Создание элементов детской конфигурации с помощью пользовательских значений.

Дублировать базовую конфигурацию.

Изменение дублируемой базовой линии и замена элементов конфигурации элементами конфигурации с измененными элементами конфигурации ребенка.

Базовые правила конфигурации

Правила базовых конфигураций используются для указания того, как должны оцениваться элементы конфигурации, включенные в базовую конфигурацию, на соответствие требованиям на клиентских компьютерах. Существуют фиксированные типы базовых правил конфигурации, которые невозможно изменить в Configuration Manager. Элементы конфигурации можно добавить в следующие базовые правила конфигурации:

Один из следующих элементов конфигурации операционной системы должен присутствовать и правильно настраиваться.

Эти приложения и элементы общей конфигурации необходимы и должны быть правильно настроены.

Если эти необязательные элементы конфигурации приложений будут обнаружены, их необходимо правильно настроить.

Эти обновления программного обеспечения должны присутствовать.

Эти элементы конфигурации приложений не должны присутствовать.

Эти базовые параметры конфигурации также должны быть проверены.

Назначение базовой конфигурации

Прежде чем клиентские компьютеры смогут оценить соответствие базовым требованиям конфигурации в Configuration Manager, базовый уровень конфигурации должен быть назначен им через наборы компьютеров.

Назначение состоит из следующих свойств:

Сама базовая конфигурация

Какая коллекция будет ориентирована на оценку соответствия требованиям и включает ли она какие-либо определенные под-коллекции

Расписание оценки соответствия требованиям, которое изначально настроено с расписанием оценки соответствия требованиям по умолчанию, но может быть изменено для каждого назначения.

Назначения базовой конфигурации являются необязательными свойствами для базовой конфигурации. Одна базовая конфигурация может быть назначена нескольким коллекциям, определяя несколько базовых назначений конфигурации.

Базовый уровень зависимой конфигурации

Одно из базовых правил конфигурации — включить другую базовую конфигурацию. Эта возможность вложения предоставляет многоуровневый метод определения базовой базовой конфигурации для широкого круга компьютеров, а затем уточнения этой базовой конфигурации с помощью дополнительных базовых конфигураций, которые имеют более конкретные конфигурации для компьютеров с похожими ролями.

Зависимые базовые показатели также используются для объединения собственных бизнес-требований с требованиями импортируемого базового уровня конфигурации (например, базовых показателей конфигурации best practices от Майкрософт), которые не могут быть непосредственно изменены. При обновлении базовой конфигурации best practices с новой версией можно импортировать более поздние версии без создания новой базовой конфигурации.

Базовые параметры зависимой конфигурации отображаются в консоли Configuration Manager в качестве свойства базовой конфигурации.

Дубликат базовой конфигурации

Дубликат базовой конфигурации в Диспетчер конфигурации — это точная копия существующей базовой конфигурации, которая не сохраняет никакого отношения к исходному. Создание базовой конфигурации с дубликатом может оказаться целесообразным, если вы хотите создать ряд аналогичных, но не связанных базовых конфигураций, и у вас есть один базовый уровень конфигурации, который используется в качестве шаблона. Другой сценарий — если необходимо пересмотреть правила или элементы конфигурации в импортируемой базовой конфигурации.

Нельзя дублировать импортированную базовую конфигурацию, если она содержит данные конфигурации, которые диспетчер конфигурации не может интерпретировать.

Элементы конфигурации

Элементы конфигурации определяют дискретную единицу конфигурации для оценки соответствия требованиям. Они могут содержать один или несколько элементов и их критерии проверки, и обычно они определяют единицу конфигурации, которую необходимо отслеживать на уровне независимых изменений.

Элементы конфигурации являются базовыми элементами конфигурации, и, следовательно, один и тот же элемент конфигурации может использоваться в нескольких базовых настройках.

Диспетчер конфигурации поддерживает следующие типы элементов конфигурации:

Элемент конфигурации операционной системы
Элемент конфигурации для определения соответствия требованиям параметров, связанных с версией и конфигурацией операционной системы.

Элемент конфигурации приложения
Элемент конфигурации для определения соответствия требованиям для приложения. Это может включать установку приложения, а также сведения о его конфигурации.

Элемент общей конфигурации
Элемент конфигурации для определения соответствия общим настройкам и объектам, где их существование не зависит от операционной системы, приложения или обновления программного обеспечения.

Элемент конфигурации обновления программного обеспечения
Элемент конфигурации для определения соответствия обновлениям программного обеспечения с помощью функции обновления программного обеспечения в Configuration Manager.

Невозможно импортировать, создавать или настраивать элементы конфигурации программного обеспечения в узле Управление конфигурацией. Вместо этого они доступны для базовых версий конфигурации с помощью функции обновления программного обеспечения при загрузке обновлений программного обеспечения. Это означает, что элементы конфигурации обновлений программного обеспечения можно выбрать для включаемого в базовые параметры конфигурации, хотя они не отображаются в узле Configuration Items.

Остальные элементы конфигурации можно импортировать, создавать и настраивать с помощью консоли Configuration Manager. Эти элементы конфигурации отображают ряд свойств, которые включают следующие:

Свойства, доступные каждому элементу конфигурации, зависят от типа элемента конфигурации. Например, можно настроить элемент конфигурации операционной системы, чтобы проверить точную версию операционной системы. Это свойство не применимо к другим пунктам конфигурации, поэтому вы не видите свойство Windows Версии, доступное для других элементов конфигурации. В следующей таблице перечислены настраиваемые свойства элемента конфигурации в диспетчере конфигурации и показано, доступно ли настраиваемое свойство для каждого типа элемента конфигурации.

Ø = Свойство не доступно

За исключением элементов конфигурации обновлений программного обеспечения, вы можете просматривать и изменять свойства каждого элемента конфигурации в узле Configuration Items в консоли Desired Configuration Management в консоли Configuration Manager. Используйте узел обновления программного обеспечения для просмотра и редактирования элементов конфигурации обновлений программного обеспечения.

В дополнение к настраиваемым свойствам элемента конфигурации в узле Desired Configuration Management также отображаются сведения аудита в свойствах General, которые показывают, когда элемент конфигурации был создан, когда он последний раз редактировался, и кем. Кроме того, на вкладке Свойства Relationships показано, как элемент конфигурации относится к другим элементам конфигурации и базовым показателям конфигурации.

Элемент конфигурации ребенка

Элемент детской конфигурации — это копия элемента конфигурации, который продолжает наследовать свойства исходного элемента конфигурации. Вы не можете изменить унаследованные объекты и параметры элементов конфигурации ребенка с их критериями проверки, но можно добавить дополнительные критерии проверки для унаследованных объектов и параметров, а также добавить новые объекты и параметры в элемент конфигурации ребенка. Обычной целью создания и редактирования элемента конфигурации ребенка является уточнение исходного элемента конфигурации для удовлетворения бизнес-требований.

Из-за зависимости свойств, унаследованных от родительского элемента к элементу конфигурации ребенка, изменение исходного элемента конфигурации влияет на элемент конфигурации ребенка.

Элементы детской конфигурации подходят, если у вас есть импортируемые данные конфигурации из базовой конфигурации best practices и вы хотите иметь возможность обновлять данные конфигурации при выпусках новых версий, которые будут продолжать передавать свои свойства на элемент конфигурации ребенка.

Другой сценарий использования элемента детской конфигурации — это сохранение наследования для точного администрирования. Например, элемент детской конфигурации можно использовать, если у вас есть элемент конфигурации, который определяет корпоративную политику безопасности, которую должны соблюдать все компьютеры, но на компьютеры финансового отдела предъявляются дополнительные требования к безопасности. В этой ситуации можно создать элемент детской конфигурации из элемента корпоративной политики безопасности. Элемент детской конфигурации наследует все свойства корпоративной политики безопасности, но он редактирован, чтобы содержать дополнительные требования к безопасности. Если корпоративная политика безопасности изменилась, исходный элемент конфигурации можно изменить без изменения элемента конфигурации для компьютеров финансового отдела. Аналогичным образом, если требования к компьютерам финансового отдела изменились, потребуется изменить только элемент детской конфигурации, а не исходный элемент конфигурации, определяя корпоративную политику безопасности.

Дубликат элемента конфигурации

Элемент дублирования конфигурации — это точная копия другого элемента конфигурации, который не сохраняет никакого отношения к исходному элементу конфигурации. Таким образом, можно использовать элемент конфигурации с дубликатом в качестве шаблона для изменения нескольких свойств и самостоятельного сохранения обоих элементов конфигурации, или использовать его при импорте элемента конфигурации только для чтения (например, из базовой конфигурации best practices) и использовать элемент конфигурации с изменением и не сохранять наследование от исходного элемента конфигурации.

Кроме того, если вы хотите использовать импортируемый элемент конфигурации, но удалить из него объекты или параметры (или связанные с ними критерии проверки), единственным вариантом редактирования является создание элемента дубликата конфигурации и соответственное изменение этого элемента конфигурации.

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.

Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.

Что такое CM и зачем он нужен

Управление конфигурацией

Для начала определимся, что такое configuration, ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».

В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.

Версия – это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.

Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.

В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).

Схема 1. Элементы, их версии и срезы-конфигурации.

CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.

Так в чем же заключается такая ценность CM?

Направления ответственности CM

Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.

Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.

Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.

Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.

Средства контроля изменений и обеспечения версионности создают условия для распараллеливания разработки в больших командах. Это достигается благодаря тому, что, описав эти средства, мы даем разработчикам документированные процедуры, позволяющие разделять ответственность и ограничивать области деятельности каждого из разработчиков.

Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.

Итак, каковы задачи управления конфигурацией?

идентификация рабочих продуктов;
стабилизация результатов работы и определение базы для дальнейшей работы;
отслеживание запросов на изменение;
контроль версий;
обеспечение параллельности разработки;
сбор метрик и формализация применяемых методов.

Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.

От вопросов, связанных с аппаратной составляющей кластера, перейдем к базовому и специализированному программному обеспечению. Заметим сразу, что в задачи данного раздела не входит обучение установке стандартных вариантов операционных систем. Это уже описано во множестве книг и предполагается, что читатель обладает необходимыми минимальными навыками и знаниями. Сосредоточимся на "кластерных" особенностях, позволяющих множеству независимых компьютеров согласованно работать в рамках единого комплекса.

Стандартом de-facto операционной системы для вычислительных кластеров в настоящее время является Linux. Какой дистрибутив предпочесть? Иногда это решает сам системный администратор , который будет поддерживать работу кластера, в некоторых случаях выбор однозначно определяется прикладным программным обеспечением, оптимизированным под конкретную версию ОС. С точки зрения собственно построения кластера большой разницы в дистрибутивах нет, однако специализированные прикладные пакеты могут оказаться к ним чувствительными. Это же касается и драйверов ко всему набору аппаратного обеспечения, особенно к новым моделям или нестандартному оборудованию.

В последнее время все большую популярность приобретает система Windows Compute Cluster Server 2003, разработанная компанией Microsoft для поддержки кластерных платформ. Вариант интересный, особенно если учесть большой объем прикладного ПО , работающего именно под MS Windows . Его миграция под кластерный вариант этого семейства операционных систем, безусловно, является лишь вопросом времени. Однако к настоящему моменту во всем мире опыта использования Windows Compute Cluster Server 2003 не много, система только недавно анонсирована, поэтому в данной работе мы будем предполагать, что выбрана ОС семейства Linux.

Рассматривая возможность использования продуктов подобного рода, нужно четко представлять возможные последствия этого решения. С одной стороны, необходимо понижать трудоемкость сопровождения и администрирования кластерных систем за счет автоматизации рутинных и предписанных регламентом процессов - это правильно, в таком направлении как раз и идет развитие данной области, в частности, для снижения стоимости владения сложными компьютерными системами. Но с другой стороны, кластерная система с самого начала должна быть максимально эффективной по отношению к задачам и оставаться такой все время своего существования. Значительным недостатком упомянутых выше продуктов является то, что в качестве основы коммуникационной среды везде предполагается Ethernet и взаимодействие через ТСР/IР, что может самым печальным образом сказаться на эффективности работы кластерной системы в целом. Если для работы в таком режиме система и ставилась, если есть уверенность, что все остается под контролем, или есть время для накопления опыта и экспериментов, то вполне можно воспользоваться и таким путем.

Установив и настроив обычный вариант операционной системы на головном узле кластера, проведем аналогичную операцию на файловом сервере. Настоятельно рекомендуем использовать Logical Volume Manager для раздела, на котором будут располагаться данные пользователей кластера. Это позволит легко проводить дальнейшее расширение хранилища и безболезненно переносить логический раздел с данными пользователей в будущем.

На головную машину операционная система ставится обычным образом. А вот для того, чтобы установить ОС на вычислительные узлы кластера, как правило, требуются дополнительные усилия. С одной стороны, на вычислительных узлах не принято устанавливать привычные в такой ситуации CD или Floppy-приводы, а с другой - установить и настроить ОС на десятках узлов само по себе является занятием долгим и утомительным.

Для упрощения процесса можно воспользоваться виртуальными приводами, если они поддерживаются сервисной сетью. Если нет, то достаточно подключить через USB или напрямую к одному из узлов CD-привод и провести установку операционной системы на этом узле.

Проведя начальную установку и стандартную настройку узла, нужно сделать еще несколько шагов для его дальнейшей работы в составе кластера. Убедитесь, что на узле установлен сервер ssh , и что пользователю root разрешен удаленный вход. Настройте беспарольный вход на узел для пользователя root , используя авторизацию по ключу, для чего воспользуйтесь командой ssh - keygen . Необходимо иметь возможность заходить на этот узел привилегированным пользователем root с головного узла - это значительно облегчит жизнь в дальнейшем.

Настройте на файловом сервере сетевой каталог, разрешив доступ к нему с вычислительных узлов и головного узла. Это можно сделать, прописав соответствующую строку в файл /etc/exports и запустив сервер NFS . Убедитесь, что сервер NFS стартует автоматически при загрузке файл-сервера .

Крайне желательно добавить в строку экспорта в файле /etc/exports опцию no_root_squash . По умолчанию NFS отменяет права суперпользователя для удаленных хостов, а указанная опция не позволяет этого сделать.

На вычислительном и головном узлах создайте каталог с одинаковым именем (например, /common или даже /home ) и настройте автоматическое монтирование в него каталога с файл-сервера . Это можно сделать, прописав соответствующую строку в файл /etc/fstab . Убедитесь, что каталог монтируется без проблем, до того как будете перезагружать узлы!

Обратите внимание на то, что многие современные дистрибутивы (такие как SuSE, RedHat, Fedora Core и другие) делают жесткую привязку настроек сетевого интерфейса к МАС-адресу сетевой карты . Если просто скопировать такие настройки на другой узел, сетевой интерфейс просто не заработает. Для того чтобы настройки можно было безболезненно перенести на любой узел, необходимо убрать привязку к МАС-адресу из файла /etc/sysconfig/network/ifcfg-eth-XXXXXX , если она там есть, переименовать этот файл в ifcfg-eth0 или ifcfg-ethl . Точно также необходимо убрать явные переименования сетевых интерфейсов в подсистеме udev . Чтобы найти остальные не столь очевидные привязки к МАС-адресу, поищите все его упоминания командой 'grep -ri MAC /etc' , где MAC замените реальным значением МАС-адреса. Узнать его можно командой ifconfig .

Синхронизация времени в системе. Она осуществляется с помощью пакета xntp или его аналогов. При существенном расхождении часов на различных узлах могут наблюдаться сбои в работе параллельных программ . Необходимо настроить ntp - сервер на головном узле, а на всех остальных узлах - клиентов, которые будут с ним синхронизироваться. При старте все узлы должны явно синхронизироваться с головным узлом командой ntpdate (она обычно входит в состав пакета xntp ), что необходимо, поскольку при большом расхождении часов клиент ntp коррекцию времени может и не выполнить.

Отслеживание состояния UPS. Большинство современных источников бесперебойного питания способны сообщать о своем текущем состоянии через СОМ-порт, USB или по сети через SNMP . Некоторые производители включают программы под Linux для отслеживания состояния UPS в поставку, но, увы, делают это далеко не все. Существует свободный пакет для мониторинга состояния UPS , который называется NUT. Он поддерживает большое число моделей UPS , но перед покупкой оборудования лучше проверить, поддерживается ли конкретная модель. NUT включает в себя сервер , снимающий данные с UPS , и клиентов. Сервер работает на головном узле, к нему же должен быть подключен управляющий кабель UPS . Клиенты должны быть установлены на все узлы. В случае отключения питания клиенты дадут команду на выключение узлов. Таким образом, можно избежать потери данных и сохранить работоспособность кластера. Если UPS достаточно мощный и может поддерживать работу кластера в течение какого-то времени, то команда выключения узлов может быть настроена на отсроченное выключение. В этом случае, если электропитание восстановится, то выключение будет отменено.

Синхронизация системных файлов ( passwd, shadow, hosts, .. .). Для того, чтобы системные изменения затрагивали не только головной узел, но весь кластер сразу, можно применять различные схемы. NIS - это одно из самых простых решений, которое, однако, чревато проблемами в случае сетевых сбоев. Следует специально отметить, что, несмотря на "простоту", хорошая настройка этой схемы может оказаться весьма нетривиальным делом для неискушенного администратора. Использование rsync является более простым решением, требующим лишь включения нужного сервиса на всех узлах и начальной настройки на головном узле. Третий вариант можно условно назвать "ручным" копированием, что предполагает использование scp в скрипте для автоматического дублирования всех нужных файлов на узлы. Каждый из перечисленных методов требует явного вызова определенной команды после изменения системных файлов. Есть и другие методы, но все они, в целом, аналогичны rsync .

Следующим шагом в настройке программного обеспечения кластерной системы является тиражирование установленной ОС на все остальные узлы. Для этого можно воспользоваться тремя схемами.

Берем любой доступный компьютер. Вставляем в него жесткий диск из вычислительного узла с уже настроенной ОС и один (или несколько) дисков из других узлов. Затем с помощью команды dd копируем на чистые диски содержимое первого диска.
Можно воспользоваться программой типа Acronis True Image или Norton Ghost для клонирования диска первого узла на диски остальных узлов.
Можно создать образ установленной ОС с помощью архиватора tar или cpio (исключите при архивировании содержимое файловых систем proc , sysfs, devfs, usbfs и им подобных). Установите syslinux . С помощью пакета sysinux и серверов dhcpd настройте сетевую загрузку. Далее нужно создать сетевой NFS-диск, на котором будет создана минимальная система, достаточная для подготовки жесткого диска (разбиение и форматирование), для разворачивания архива с образом ОС и установки загрузчика . Убедитесь, что ядро данной минимальной системы поддерживает корневой каталог на NFS. Затем скопируйте в каталог сетевого диска образ ОС и в качестве стартового сделайте скрипт, который автоматически установит это образ. После этого произведите сетевую загрузку всех узлов, где операционная система еще не установлена.

Третий способ, конечно, сложнее, но он более универсален и позволяет в дальнейшем быстро добавлять новые узлы и восстанавливать испорченные простой перезагрузкой (с указанием "грузиться по сети"). Для подготовки минимальной системы, которая будет грузиться по сети и устанавливать ОС на узлы, можно воспользоваться любым мини-дистрибутивом из сети Интернет или подмножеством программ из уже имеющегося дистрибутива.

В минимальной системе обязательно должны присутствовать: bash, tar (или cpio ), sfdisk, mke2fs ( mkreiserfs или иное в зависимости от выбранной файловой системы), полный пакет grub (или lilo ) и набор библиотек с динамическим линкером, необходимые для работы этих программ.

С помощью программы sfdisk можно записать в файл разметку жесткого диска с первого узла и в стартовом скрипте использовать ее для разметки жестких дисков чистых узлов.

О безопасности кластера нужно позаботиться заранее. Не стоит полагаться на соображения типа: "Да кому нужно взламывать наш кластер ?". Будьте уверены, что желающих найдется много. Совсем не обязательно их целью будет помешать вашей работе. Скорее всего, задачей станет использовать взломанные компьютеры как плацдарм для будущих хакерских действий или рассылки спама.

О том, как повысить безопасность Linux-сервера, написано немало книг и статей, желательно с ними ознакомиться. Приведем лишь несколько основных советов.

Для удаленного входа на кластер и удаленной передачи файлов используйте ssh . Под Windows есть немало программ, реализующих этот протокол, например, свободно распространяемая программа putty . He используйте для этих целей telnet, ftp, nfs или samba (windows share).
Отключите все ненужные сервисы.
Включите файрволл, продумайте политику его использования.
По возможности, дополнительно ограничьте доступ пользователей. Это можно сделать, задав список адресов, с которых разрешено заходить на головной узел, либо запретив авторизацию по паролю и обязав пользователей использовать для авторизации ключи.
Включите "устаревание" паролей пользователей.
Включите проверку сложности паролей.
Установите одну из программ проверки целостности системы (такую, как tiger, ossec, tripware ).
Регулярно проверяйте журналы на головном узле, воспользуйтесь пакетом logcheck или logwatch .
Время от времени проверяйте систему на наличие "закладок" программами типа chkrootkit, rkhunter . He храните эти программы в доступном с головного узла каталоге, лучше запускайте их с USB-Flash или с дискеты.

О том, как произвести такие настройки, можно прочесть в man-страничках chage, sshd, sshd_config, pam , а также В документации к упомянутым пакетам. Подчеркнем еще раз: обеспечение безопасности - это очень важный вопрос. Сразу уделите безопасности особое внимание, поскольку решение этих проблем после обнаружения факта взлома уже может быть сопряжено с потерями.

В данном разделе мы сразу предположили использование NFS в качестве сетевой файловой системы кластера. Она хорошо известна, у многих есть опыт ее использования, поэтому именно на NFS чаще всего останавливается выбор администраторов. Но хочется предостеречь сразу: этот вариант, во-первых, не единственный и, во-вторых, совсем не идеальный. Основное слабое место связано с плохой масштабируемостью NFS и очень сильным падением характеристик ее работы при увеличении числа узлов. Какова цель кластерного проекта и чего хотелось бы достичь? Максимум процессоров, максимум "флопсов"? Бывает и такое. В частности, именно такие требования выдвигают некоторые масштабные задачи физики высоких энергий, для которых чем больше в компьютерной системе вычислительных узлов, тем лучше. Если говорить про общий случай, то каждое приложение устанавливает некоторый порог, соотношение между вычислительными способностями кластера и характеристиками подсистем ввода/вывода, за которым выполнение приложения перестает быть эффективным, а использование кластера становится полностью нецелесообразным. Для параллельных приложений порог может меняться в зависимости от числа используемых процессоров, что создает дополнительные трудности в его определении на практике. Но сделать это необходимо, причем сделать на этапе проектирования архитектуры, чтобы вместо сбалансированной кластерной системы не получить однобоко развитого монстра. Здесь уместно вспомнить определение суперкомпьютера, приведенное в предисловии данной книги, согласно которому в системах подобного класса "проблема вычислений сводится к проблеме ввода/вывода".

Альтернативные варианты файловых систем, к которым стоит приглядеться: Panasas File System , Lustre, Terragrid, Parallel Virtual File System (PVFS2), General Parallel File System (GPFS). Данные файловые системы изначально предназначались для параллельных компьютеров, они активно развиваются и реально используются на многих больших кластерных системах. Имеет смысл подумать об этих вариантах. Сделать "как все" не означает принять оптимальное для себя решение: не исключено, что именно данные файловые системы лучше всего подойдут для решения задач проекта.

Итак, на все узлы кластера установлена операционная система , проведена начальная настройка, кластер "задышал". Следующим шагом будет переход к содержательной работе кластера и запуск параллельных программ . Для этого нам нужен набор компиляторов, одна или несколько сред параллельного программирования, дополнительные библиотеки и пакеты, специализированные прикладные системы.

Под конфигурацией ПО понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.

В крупном проекте большие объемы информации меняются очень быстро и неконтролируемые изменения могут быстро ввергнуть проект в хаос. Работая над программным проектом, группа программистов, тестеров и менеджеров сталкивается с проблемой отслеживания версий программ, внесения в них изменений. Чем больше проект, тем больше времени разработчики тратят на согласования изменений в исходных текстах и получения работающих версий программного продукта. Данная задача может усугубиться наличием в компании регионально удаленных групп-разработчиков.

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

При групповой разработке сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, необходимо:

- выделить набор объектов, определяющих структуру будущей системы, чтобы затем контролировать их состояния и ход работ по каждому из них. Такими объектами могут быть функционально-логическая модель системы, реляционная модель базы данных, модули прототипов системы (экраны, меню, отчеты, тексты процедур или классов), системные и программные спецификации, документация, планы проведения тестирования, спецификации тестовых процедур;

- вести журнал всех изменений, внесенных в систему в процессе разработки или сопровождения (это касается состояния создаваемой системы, бюджета, сроков, интерфейса, контрольных отчетов и т.д.);

- вести полный и достоверный архив всех версий всех объектов системы;

- контролировать состояние и развитие коллективно используемых компонентов ПО и их версий, учитывая связи компонентов системы для согласования между собой измененных частей; обеспечивать адекватность реально изменяющихся компонентов и их комплектной документации;

- изготавливать эталонные копии ПО и документации, хранить и поставлять их пользователям в соответствии с порядком, принятым в организации. Это упрощает выпуск и поставку ПО;

- обеспечивать развитие всей системы, ограничивая усложнение проекта.

Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Рассмотрим, как пример, управление исходным кодом.

Для групповой разработки важны системы контроля исходного кода. Такие системы решают, по крайней мере, две задачи: хранение всех версий каждого экземпляра исходного кода (версии файлов) и разрешение конфликтов одновременного доступа разработчиков к одному экземпляру исходного кода (слияние исходных текстов, согласованность группы файлов проекта и т.п.).

Контролю подвергается не только собственно код модулей, но и код скриптов генерации схемы базы данных, а также собственно схема базы данных, которая может храниться в виде версий бинарных файлов, экспортированных во внутренний формат СУБД схем баз данных.

Прикладные программисты должны придерживаться установленных правил групповой разработки.

Формат комментария к правке может быть таким:

10.01.2004 Ivanov: authorization bug fixed (found by Petrov)

Это делается для того, чтобы через некоторое время можно было понять, кто и зачем внес данную правку. Также это помогает корректировать слияние исходного кода, если система контроля обнаружила несовместность правок и не может разрешить ее сама.

Часто ведущие исполнители проектов не доверяют системам контроля исходного кода сливать правки в исходных текстах автоматически и частично или полностью контролируют этот процесс. Эта перестраховка во многих случаях себя оправдывает.

Также в начале исходного кода (в комментариях) описывается: для чего данный файл исходного кода создан, основные его функции, к какой части информационной системы он относится, кто автор.

Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида K1, Function10.

Такой подход облегчает взаимодействие разработчиков разных модулей. Документировать нужно только интерфейс обмена, а не весь код модуля целиком.

Взаимодействие компонентов не должно быть произвольным. Контролировать эти правила создания исходного кода в большинстве случаев приходится вручную.

Группа разработчиков должна иметь свой выделенный сервер баз данных, и, возможно, не один, а также выделенные рабочие места. Часто эти моменты далеко не очевидны руководству, и оно воспринимает это как совершенно ненужную трату средств. Сервер, обеспечивающий контроль исходного кода, также должен быть выделенным.

Рынок систем конфигурационного управления

Без хорошего инструментария невозможно оперативно управлять конфигурациями ПО.

Специализированные системы конфигурационного управления позволяют выполнять автоматизированную сборку готового продукта из множества изменяющихся частей по типовой схеме, исключая "человеческий фактор" на этом рутинном этапе, а, следовательно, и дорогостоящие ошибки.

Можно выделить четыре группы таких продуктов:

1) обеспечивающие контроль версий (Rational ClearCase, Merant PVCS, Microsoft Visual SourceSafe);

2) обеспечивающие контроль версий и изменений (Rational ClearCase/ClearQuest, PVCS Professional);

3) обеспечивающие параллельную разработку, контроль версий, изменений и рабочих процессов (PVCS Dimensions, CCC:Harvest фирмы Computer Associates);

4) обеспечивающие все вышеуказанные возможности при взаимодействии нескольких географически удаленных команд (Rational MultiSite, PVCS Replicator).

Продукт ClearCase наиболее мощный и, соответственно, дорогой. Он лучше всего подходит для проектов, в которых участвует не менее 10 разработчиков и которые направлены на создание крупных систем или на выпуск тиражируемого ПО, когда особенно актуальны проблемы отслеживания версий. ClearCase поддерживает множество репозитариев проекта с их автоматической синхронизацией; координирует совместную работу всех участников проекта; управляет конфигурацией сборки ПО; обеспечивает визуальный контроль над происходящим.

Продукт PVCS, встроен во многие системы разработки, предлагает более простой версионный контроль. Он хуже автоматизирует работу пользователей и сложнее в применении, но зато не требует отдельного сотрудника-администратора для поддержки небольших групп разработчиков. Существуют проблемы переходов от одного продукта PVCS к другому. Имеет меньшую стоимость. Может оказаться хорошим решением, если разработка идет под разными платформами (аппаратная платформа и ОС).

Продукт Microsoft Visual Source Safe осуществляет простой контроль исходных текстов и подходит для индивидуальной работы или для проектов, объединяющих нескольких человек. В нем нельзя организовать связь между участниками проекта, но он значительно дешевле и проще. Используется для ОС Windows 98, NT, 2000.

В ноябре 2002 г. компания Merant выпустила новую версию популярного инструмента для управления конфигурациями ПО PVCS Professional 7.5.

В состав пакета входят:

Срочно?
Закажи у профессионала, через форму заявки
8 (800) 100-77-13 с 7.00 до 22.00

Установка программного и аппаратного обеспечения на компьютере на сегодня состоит из самых элементарных компьютерных знаний. В этой статье нашего сайта, мы кратко рассмотрим, как можно правильно выполнить оба этих типа процессов и их установку. На сегодняшней день компьютеры стали неотъемлемой частью нашей жизни. Мы можем найти их везде вокруг нас. Они имеют множество существенных и важных приложений в различных областях, включая промышленность, сельское хозяйство, научные исследования, медицина и т. д.
Но для большинства из нас термин означает компьютер ПК, который мы используем в наших домах и офисах. Мы используем их, чтобы смотреть фильмы, слушать музыку, играть в игры, работать с документами и т. д. И на сегодняшний день действительно невозможно обойтись без компьютера в нашей повседневной жизни, в наших домах и на рабочих местах.

Так как мы используем компьютеры так широко, нам необходимо иметь некоторое представление как минимум об установке его основных составляющих, а именно аппаратного и программного обеспечения. Эти знания могут оказаться жизненно важными, особенно, когда мы хотим обновить ПК.

В самом общем смысле, компьютерная программа представляет собой программу, которая работает в нём, тогда как аппаратная часть представляет собой монитор, клавиатуру и другие периферийные устройства, подключенные к нему. Оба этих компонента необходимы для работы любой компьютерной системы.

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

Установка программного обеспечения

Операционная система вашего компьютера является важным фактором, который следует учитывать при установке любого программного обеспечения. Это базовая программа, которая предназначена для управления аппаратными и программными ресурсами компьютера.

Перед установкой программного обеспечения, первым важным шагом является проверка конфигурации вашего компьютера и системных требований программного обеспечения. Конфигурация компьютера должна соответствовать требованиям программного обеспечения для её установки.

Иногда, программа для установки сжимается в .rar или .zip-файл. В этих случаях, перед установкой, вы должны распаковать эти файлы и папки. Для этого важно, чтобы у вас было программное приложение для декомпрессии, установленное на вашем компьютере.

Перед установкой любого программного обеспечения, рекомендуется закрыть все другие программы и утилиты. Некоторые антивирусные приложения могут потребовать от вас, чтобы отключить брандмауэр и отключить антивирус, чтобы установить его. Особенно при установке программного приложения, относящихся к области компьютерных сетей или веб-браузерам, и тогда рекомендуется отключить антивирус и брандмауэр, прежде чем продолжить установку. Наконец, для завершения установки может потребоваться перезагрузить компьютер.

Установка компьютерного оборудования

С технологией продвижения, компьютерные периферийные устройства стали достаточно часто обновляться, и многие новые и лучшие устройства доступны каждый день. Чтобы установить один или более из них в существующую систему, необходимо сначала отсоединить все кабели питания компьютера, подключенные к электросети, прежде чем перейти к подключению аппаратуры.

Пакет оборудования может включать в себя сопроводительный компакт-диск, содержащий программное обеспечение, которое поможет ОС вашего компьютера в признании нового оборудования. Перед подключением устройства к компьютеру, установите это программное обеспечение, которое должно быть перезапущено после установки с компакт-диска. Существуют два различных вида вычислительной техники. Они заключаются в следующем:

Внешнее оборудование
Внешнее оборудование включает в себя все периферийные устройства, подключенные к компьютеру извне, через различные порты. Это USB порты, последовательный и параллельный порт, порт FireWire, блютуз, PS/2 и PC-карты. Внешний монтаж оборудования может сделать обычный пользователь, даже без особых знаний компьютера. Они могут быть подключены непосредственно к компьютеру, как только он будет выключен.

Внутреннее оборудование
Внутреннее оборудование немного сложнее и требует некоторых базовых знаний о внутреннем устройстве компьютера. Системный блок должен быть открыт путем удаления боковых панелей. Затем вы должны определить слот, в который вы должны подключить ваше оборудование. После этого, вы должны подключить оборудование, которое устанавливается и убедитесь, что оно правильно встало в свою щель.

После установки оборудования, на боковой панели винты должны быть установлены на своих прежних местах, и все провода должны быть подключены к соответствующим слотам. Затем к сети обратно может быть подключен шнур питания, и компьютер включается.

Большинство компьютерных программ и установка оборудования может легко осуществляться с помощью некоторых базовых знаний о компьютерах. Если процедура установки слишком сложная, вы должны попросить профессионала, чтобы он установил или помог Вам с этим.

Читайте также: