- •Введение
- •7. Иерархия памяти
- •7.1. Основы
- •7.2. Организация кэш-памяти
- •7.2.1. Параметры описания кэш-памяти и ее иерархия
- •7.2.2. Увеличение производительности кэш-памяти
- •7.3. Принципы организации основной памяти в современных компьютерах
- •7.3.1. Общие положения
- •7.3.2. Увеличение разрядности основной памяти
- •7.3.3. Память с расслоением
- •7.3.4. Использование специфических свойств динамических зупв
- •7.4. Виртуальная память и организация защиты памяти
- •7.4.1. Концепция виртуальной памяти
- •7.4.2. Страничная организация памяти
- •7.4.3. Сегментация памяти
- •8. Современные микропроцессоры
- •8.1. Процессоры с архитектурой 80x86 и Pentium
- •8.2. Особенности процессоров с архитектурой sparc компании Sun Microsystems
- •8.3. Процессоры pa-risc компании Hewlett-Packard
- •8.4. Процессор mc88110 компании Motorola
- •8.5. Особенности архитектуры mips компании mips Technology
- •8.6. Особенности архитектуры Alpha компании dec
- •8.7. Особенности архитектуры power компании ibm и PowerPc компаний Motorola, Apple и ibm
- •8.7.1. Архитектура power
- •8.7.2. Эволюция архитектуры power в направлении архитектуры PowerPc
- •8.7.4. Процессор PowerPc 603
- •9. Организация ввода/вывода
- •9.1. Общие положения
- •9.2. Системные и локальные шины
- •9.2.1. Центральная шина
- •9.2.2. Стандарты шин
- •9.3. Устройства ввода/вывода
- •9.3.1. Основные типы устройств ввода/вывода
- •9.3.2. Магнитные и магнитооптические диски
- •9.3.3. Дисковые массивы и уровни raid
- •9.3.4. Устройства архивирования информации
- •10. Многопроцессорные системы
- •10.1. Классификация систем параллельной обработки данных
- •10.2. Модели связи и архитектуры памяти
- •10.3. Многопроцессорные системы с общей памятью
- •10.3.1. Мультипроцессорная когерентность кэш-памяти
- •10.3.2. Альтернативные протоколы
- •10.4. Основы реализации
- •11. Системы высокой готовности и отказоустойчивые системы
- •11.1. Основные определения
- •11.2. Подсистемы внешней памяти высокой готовности
- •11.3. Требования, предъявляемые к системам высокой готовности
- •11.3.1. Конфигурации систем высокой готовности
- •11.3.2. Требования начальной установки системы
- •11.3.3. Требования к системному программному обеспечению
- •11.3.4. Журнализация файловой системы
- •11.3.5. Изоляция неисправного процесса
- •11.3.6. Мониторы обработки транзакций
- •11.3.7. Другие функции программного обеспечения
- •11.3.8. Требования высокой готовности к прикладному программному обеспечению
- •11.3.9. Требования к сетевой организации и к коммуникациям
- •11.4. "Кластеризация" как способ обеспечения высокой готовности системы
- •11.4.1. Базовая модель vax/vms кластеров
- •11.4.2. Системное программное обеспечение vax-кластеров
- •11.4.3. Критерии оценки кластеров Gartner Group
- •11.4.4. Кластеры Alpha/osf компании dec
- •11.4.5. Unix-кластеры компании ibm
- •11.4.6. Кластеры at&t gis
- •11.4.7. Кластеры Sequent Computer Systems
- •11.4.8. Системы высокой готовности Hewlett-Packard
- •11.4.9. Кластерные решения Sun Microsystems
- •11.4.10. Отказоустойчивые решения Data General
- •Список использованных источников
11.3.2. Требования начальной установки системы
Большинство систем высокой готовности требуют включения в свой состав процедур начальной установки (System Setup), обеспечивающих конфигурацию кластера для подобающего выполнения процедур переключения, необходимых в случае отказа. Пользователи могут запрограммировать "скрипты" начальной установки самостоятельно или попросить системного интегратора или поставщика проделать эту работу. В зависимости от того, насколько сложна начальная установка системы, и в зависимости от типа системы, с которой мигрирует пользователь, написание "скриптов", которые управляют действиями системы высокой готовности в случае отказа, может занять от одного - двух дней до нескольких недель или даже месяцев для опытных программистов. Многие поставщики обеспечивают несколько стандартных "скриптов" начальной установки. Кроме того, некоторые из них предоставляют сервисные услуги по начальной установке конфигурации, которые включают программирование сценариев переключения на горячий резерв в случае отказа, а также осуществляют работу с заказчиком по написанию или модификации "скриптов". Пользователи могут самостоятельно создавать "скрипты", однако для реализации подобающей конфигурации требуется высококвалифицированный программист - знаток UNIX и C.
Время простоя при переключении системы на резервную для систем высокой готовности может меняться в диапазоне от нескольких секунд до 20-40 и более минут. Процедура переключения на резерв включает в себя следующие этапы: резервная машина обнаруживает отказ основной и затем следует предписаниям скрипта, который вероятнее всего включает перезапуск системы, передачу адресов пользователей, получение и запуск необходимых приложений, а также выполнение определенных шагов по обеспечению корректного состояния данных. Время восстановления зависит главным образом от того, насколько быстро вторая машина сможет получить и запустить приложения, а также от того, насколько быстро операционная система и приложения, такие как базы данных или мониторы транзакций, смогут получить приведенные в порядок данные.
В общем случае аппаратное переключение на резерв занимает по порядку величины одну - две минуты, а система перезагружается за следующие одну - две минуты. В большинстве случаев от 5 до 20 минут требуется на то, чтобы получить и запустить приложение с полностью восстановленными данными. В противном случае пользователи инструктируются о необходимости заново ввести последнюю транзакцию.
Накладные системные расходы зависят от типа используемой системы и от сложности процедур ее начальной установки. Для простых процедур начальной установки при переходе на резерв они очень небольшие: от долей процента до 1.5%. Однако, чтобы получить истинную стоимость накладных расходов к этим накладным расходам необходимо добавить еще потери, связанные с недоиспользованием процессорной мощности резервной системы. Хотя покупатели стремятся использовать резервную систему для некритических приложений, она оказывается менее загруженной по сравнению с основной системой. Истинно кластерные системы, такие как VAXclasters компании DEC или кластер LifeKeeper Claster отделения NCR компании AT&T, являются примерами намного более сложного управления по сравнению с простыми процедурами начальной установки при переключении на резерв, и полностью используют все доступные процессоры. Однако организация таких систем влечет за собой и большие накладные расходы, которые увеличиваются с ростом числа узлов в кластере.