Что такое горячий и холодный резерв генератора. Холодный резерв – rpo rto. Включение резервного оборудования замещением. Холодное и горячее резервирование

Примером FC SAN является даже прямое соединение между сервером и СХД т.к. на сервере используется FC HBA (подробнее в разделе Комоненты) внутри сервера. Недостаток direct – невозможно без остановки сервера подключить доп. СХД к серверу. Single-switch/dual-switch – подключение серверов к СХД через FC-коммутаторы, dual-switch, понятно, для отказоустойчивости/балансинга.

Преимущества FC SAN

Производительность (FC до 16гб/с), централизованное/гибкое управление, динамическая утилизация ресурсов, трафик не грузит LAN, масштабируемость, совместимость с SCSI устройствами хранения (особенно важно было при старте FC, не потребовало ничего менять на серверах).

Fibre Channel

Fibre Channel (FC) – стек протоколов типа TCP/IP. Правильно писать именно Fibre channel, а не Fiber. Есть теория, что так, потому что стандарт, в теории, поддерживает медные кабеля, помимо по факту везде используемых оптических.

FC описан в ряде стандартов, внизу скрин со стандартами в зависимости от уровня имплементации.

В стеке FC 5 уровней с похожей на TCP/IP схемой энкапсуляции:

• FC-0 – физика и сигнализация
• FC-1 – кодирование и декодирование
• FC-2 – соглашения по структуре данных
• FC-3 – сервисы – мало используется
• FC-4 – взаимодействие FC с другими высокоуровневыми протоколами – SCSI-3 (в основном) или IP, ATM. То есть FC может транспортировать IP-пакеты, а не только IP может FC-кадры переносить (iSCSI, подробнее в статье ).

Пример энкапсулиции SCSI команд в стек FC.

Адресация

Каждое устройство в сети Fiber Channel имеет уникальный номер WWN. WNN бывает двух видов, под оба выделено 64 бита, со своей частью под Vendor ID:

WWNN (World Wide Node Name) – идентификация хоста в FC сети.

WWPN (World Wide Port Name) – идентификация конкретного порта на конкретном хосте в FC сети. Применение похоже на применение MAC-адреса в сети Ethernet.

Не проверенная инфа из вебинара: при подключении устройства к сети FC на основе WWNN делается 24-битный адрес устройства WWPN из-за ограничения поля адреса в FC в 24 бита. Сопоставлением имен WWNN и WWPN занимаются FC-коммутаторы.

Логические топологии

В сетях FC бывают три варианта топологий:

• Point-to-point – прямое подключение двух устройств
• Arbitrated loop – кольцо FC через FC-хабы с возможностью подключения до 27 устройств. Старая схема, проблемы со скоростью и доступом к среде, малое количество устройств. В текущий момент не используется.
• Switched fabric – коммутируемая среда через FC-коммутаторы, вытеснило loop. До 16 миллионов устройств и 239 коммутаторов в одной FC сети.

Типы портов

Типы портов в FC-сетях:

• N_Port (Node Port) – порт оконечного устройства в сторону фабрики (свича)
• F_Port (Fabric Port) – порт фабрики (свича) в сторону оконечного устройства
• E_Port (Expansion Port) – порт в сторону другого FC-коммутатора
• G_Port (General Port) – универсальный порт. В зависимости от подключенного к нему устройства работает как F_Port или E_Port.
• NL_Port (NodeLoop Port) – порт оконечного устройства в сторону хаба в топологии arbitrated loop (Fabric)
• FL_Port (FabricLoop Port) – порт хаба в сторону оконечного устройства в топологии arbitrated loop (Node) или порт фабрики (свича) в сторону хаба и наборот

Компоненты сети хранения FC

• Storage device – устройство хранения (СХД, ленточные библиотеки)
• FC коммутаторы – промежуточные устройства (судя по вебинару есть так же FC роутеры), часто на них поднят iSNS сервер для работы (см. в статье )
• HBA (Host Bus Adapter) – по сути NIC сервера в FC SAN. Обычно HBA подключаются в PCI-e интерфейс на сервере/контроллере СХД. В FC используется оптика, поэтому HBA, помимо прочего, выполняет функцию преобразования электрических сигналов в оптические (и наоборот).
• Optical fiber – среда передачи

Подключение устройств Storage device () к сети FC делается через специальные FC порты на FC платах СХД. Это могут быть обычные FC платы или платы FCoe, с возможностью передачи FC-кадров через Ethernet (энкапсуляция FC в Ethernet).

FC коммутаторы имеют порты под SFP FC (или gbic/xfp). Только в редких случаях порты бывают не SFP, а с жесткой заточкой под определенный тип FC.

FC коммутаторы имеют поддержку Zoning – зонирование сети FC, что-то типо VLAN на Ethernet коммутаторах. Позволяет делить сеть FC на отдельные участки. Используется для упрощения администрирования, улучшения безопасности, увеличения производительности. Одно устройство может входить сразу в несколько зон.

Есть два основных режима зонирования :

• зонирование по портам или жесткое зонирование (port zoning/hard zoning) – порты закрепляются за зонами. Сопоставление port-zone настраивается на FC коммутаторе. Прямые операции по адресу между устройств разных зон запрещаются.
• зонирование по имени или мягкое зонирование (WWN zoning/soft zoning) – на основе WWNN серверу назначается зона. Сопоставление WWN-zone настраивается на FC коммутаторе. Прямые операции между устройств разных зон не запрещаются. Удобно использовать при частых подключениях устройств в разные порты. alias zoning – простой в настройке подвид soft zoning, WWNN для удобства сопоставляется придуманный тобой alias.

HBA бывают SCSI, FB. Имеют часто возможность вставления SFP. Бывают многопортовые HBA. Наиболее популярные вендоры: Brocade, Emulex, Qlogic.

Скорость и расстояние в технологии FC в зависимости от используемой Optical fiber. Расстояние от 0.5 метра до 50км (без использования промежуточных FC свичей). Лимит на минимальное сделан во избежание слишком мощного сигнала, в противном случае нужно ставить аттенюаторы. Скорость до 16Gbit/s. Внутри ЦОД чаще всего используют многомод. На многомоде расстояние до 500м, причем уменьшение скорости пропорционально увеличению расстояния.

Типичная отказоустойчивая схема подключения компонентов FC SAN : подключение СХД (два контроллера) к серверу (два HBA) через FC-свичи. Два коммутатора не только для отказоустойчивости/балансинга, но и потому, что “desing of Fibre channel SAN’s demands it. An FC SAN must consist of two separate networks called fabrics”. Можно и больше коммутаторов, подключенных как угодно (кольцо, звезда, full/partial mesh).

Multipath

При наличии нескольких портов на NIC/HBA на уровне отдельного софта или операционной системы может быть реализован функционал типа LAG. В терминологии сетей хранения это называется Multipath . В случае использования отдельного софта, софт должен быть совместим с текущей ОС. Если ОС не поддерживает Multipath нативно или софт который этот функционал предоставляет не поддерживает работы в этой ОС – один LUN может быть виден каждым портом хоста как отдельный LUN, а не единый.

Сравнение FC SAN с IP SAN и Конвергенция FC SAN и IP SAN

Вопросы

Fibre Channel использует пакеты переменной длины (до 2148 байт ), содержащие до 2112 байт данных. Такая длина пакета заметно снижает издержки, связанные с пересылкой заголовков (эффективность 98%). С этой точки зрения в наихудшем положении оказывается ATM (83% эффективность 48 байт данных при 53-байтном пакете). Только FDDI превосходит Fibre Channel по этому параметру (99%). В отличие от других локальных сетей, использующих 6-октетные адреса, fibre channel работает с 3-байтовыми адресами, распределяемыми динамически в процессе выполнения операции login . Адрес 0xffffff зарезервирован для широковещательной адресации. Адреса же в диапазоне 0xfffff0-0xfffffe выделены для обращения к структуре fabric , мультикастинг-серверу и серверу псевдонимов (alias-server). n_port передает кадры от своего source_id (s_id) к destination_id (d_id). До выполнения операции fabric login s_id порта не определен. В случае арбитражного кольца применяются 3-октетные адреса al_pa, задаваемые при инициализации кольца. Для однозначной идентификации узлов используются 64-битовые имена-идентификаторы.

Формат пакетов в сетях Fibre Channel показан на рис. 14.7 . Здесь используются 24-битовые адреса, что позволяет адресовать до 16 миллионов объектов. Сеть может строить соединения по схеме " точка-точка ", допускается и кольцевая архитектура с возможностью арбитража (FC-al) и другие схемы (например fabric , допускающие большое число независимых обменов одновременно). Схема кольцевого соединения показана на рис. 14.8 . К кольцу может быть подключено до 128 узлов. Протокол Fibre Channel предусматривает 5 уровней, которые определяют физическую среду, скорости передачи, схему кодирования, форматы пакетов, управление потоком и различные виды услуг. На физическом уровне ( FC-ph , 1993 год) предусмотрены три подуровня. FC использует оптические волокна диаметром 62,5, 50 мкм и одномодовые. Для обеспечения безопасности предусмотрен опционный контроль подключенности оптического разъема ( OFC ). Для этого передатчик время от времени посылает короткие световые импульсы приемнику. Если приемник получает такой импульс, процесс обмена продолжается ( таблица 14.12 .).

Рис. 14.7.

FC-0 и FC-1 образуют физический уровень , соответствующий стандартной модели ISO .

Стандарт FC допускает соединение типа " точка-точка ", "арбитражное кольцо" и "структура" (верх, середина и низ рисунка 14.8). Кольцевая архитектура обеспечивает самое дешевое подключение. Система арбитража допускает обмен только между двумя узлами одновременно. Следует учесть, что кольцевая структура не предполагает применения маркерной схемы доступа . Когда подключенное к сети устройство готово передать данные, оно передает сигнал-примитив ARBX, где X - физический адрес устройства в кольце арбитража (al_pa). Если устройство получит свой собственный сигнал-примитив ARBX, оно получает контроль над кольцом и может начать передачу. Инициатор обмена посылает сигнал-примитив open (OPN) и устанавливает связь с адресатом. Время удержания контроля над кольцом не лимитируется. Если контроль над кольцом одновременно пытаются захватить два устройства, сравниваются значения X сигналов ARB. Устройство с меньшим al_pa получает преимущество, прибор с большим al_pa блокируется.

Прежде чем использовать кольцо, его нужно инициализировать (процедура LIP ), так чтобы каждый порт получил свой физический адрес (al_pa - один октет , что и определяет максимальное число портов в кольце арбитража). Процедура инициализации начинается сразу после включения питания посылкой сигнала -примитива LIP через порт l_port. Затем осуществляется выбор устройства, которое будет управлять процессом выбора al_pa.

Перед передачей октеты преобразуются в 10-битовые кодовые последовательности, называемые символами передачи ( кодировка IBM 8B/10B ). Логической единице соответствует больший уровень световой энергии.

В Fibre Channel предусмотрено два режима обмена: "буфер-буфер" и " точка-точка ". Передача данных осуществляется, только когда принимающая сторона готова к этому. Прежде чем что-либо посылать, стороны должны выполнить операцию login . В ходе выполнения операции login определяется верхний предел объема пересылаемых данных (credit). Значение параметра credit задает число кадров, которые могут быть приняты. После передачи очередного кадра значение credit уменьшается на единицу. Когда значение этой переменной достигает нуля, дальнейшая передача блокируется до тех пор, пока получатель не обработает один или более кадров и не будет готов продолжить прием. Здесь очевидна довольно тесная аналогия с окнами в протоколе TCP . Режим обмена "буфер-буфер" предполагает установление связи между портами N_Port и F_Port или между двумя N_Port. При установлении соединения каждая из сторон сообщает партнеру, сколько кадров она готова принять ( значение переменной BB_Credit). Режим " точка-точка " реализуется между портами типа N_Port. Предельное число кадров, которые сторона может принять, задается переменной EE_Credit. Эта переменная устанавливается равной нулю при инициализации, увеличивается на единицу при передаче кадра и уменьшается при получении кадра ACK Link Control . Кадр ACK может указывать на то, что порт получил и обработал один кадр , N кадров или всю последовательность кадров. (См. также Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard . K. Teow. May 2000, RFC-2837.)

14.2. Параллельный сетевой интерфейс HIPPI

Все рассматриваемые до сих пор системы передачи информации использовали исключительно последовательный код. На разных этапах эволюции телекоммуникаций предпочтение отдавалось и параллельному, и последовательному методам обмена данными. В данный момент параллельный интерфейс сохранился только для подключения принтеров. Главным преимуществом последовательных схем передачи информации является экономия на кабелях. Ниже описан еще один стандарт, где применен параллельный интерфейс (начало разработки относится к 1987 году). HIPPI (High Performance Parallel Interface , см. ftp://ftp.network.com ; http://www.cern.ch/hsi/hippi/spec/introduc.htm ; RFC-2067, IP over HIPPI , J. Renwick; RFC-1374, IP and ARP on HIPPI , J. Renwick, ANSI x3t9.3/90-043, 1990 и X3t9.3/91-005) представляет собой быстродействующий параллельный интерфейс , рассчитанный на пропускную способность 800 Мбит/с (но возможны версии со 100, 200 400 и 1600 Мбит/с). Разработка интерфейса выполнена в Лос-Аламосе. Позднее на базе этого интерфейса была подготовлена идеология сети.

Длина кода, передаваемого за один такт в HIPPI , составляет 32 разряда (версия HIPPI , рассчитанная на скорость 1600 Мбит/с, имеет длину кода 64 бита). Все пересылки являются симплексными. Существует стандарт Superhippi (HIPPI -6400, 6,4 Гбайт/с), который описывает систему передачи данных, в 8 раз более быстродействующую, чем HIPPI . Разработана версия последовательного HIPPI на скорость обмена 1,2 Гбод для коаксиального и оптоволоконного кабеля (до 10 км; версия HIPPI -FC - fiber channel ). Максимальное расстояние между станцией и переключателем составляет 25 м. Максимальное расстояние между станциями ("станция- переключатель -станция") равно 50 м. Предельное число станций зависит от типа используемых переключателей. Переключатели могут взаимодействовать друг с другом (HIPPI -SC), обеспечивая информационный обмен между станциями. Пример топологии сети HIPPI представлен на

Fibre Channel - высокоскоростной интерфейс передачи данных с устройствами хранения данных (преимущественно HDD). Наиболее актуальная его модификация называется FC-AL (Fibre Channel Arbitrated Loop) - она способна передавать данные со скоростью от 1 до 4 Гбит/с на расстояние до 10 км. Жесткие диски с таким интерфейсом используются в высокопроизводительных современных системах хранения данных.

Функционально этот интерфейс больше похож на Ethernet, особенно в части перенаправления информационных потоков. Неопытные пользователи часто путают выполненные оптическим кабелям Ethernet сети, с настоящей Fibre Channel, которая удачно объединила в себе производительность SCSI шин и многофункциональность сетевых интерфейсов.

Скоростные характеристики Fibre Channel нормируются тремя стандартами - 1 Гбит/сек, 2 Гбит/сек и 4 Гбит/сек. Учитывая, построенная на таком интерфейсе сеть считается полудуплексной. То есть физически все устройства соединяются парой оптоволоконных кабелей, по одному из которых идет исходящий, по второму входящий информационный поток. Такое техническое решение позволяет при равном соотношении объема обоих потоков получить реальное удвоение скорости передачи относительно заявленной. Для возрастающих потребностей пользователей активно внедряется технология Fibre Channel обеспечивающая построение информационного канала 10 Гбит/сек, и этот показатель не является предельным. По соотношению цена/производительность из всей сетевой номенклатуры лидирует 2 гигабитный вариант.

Допустимая протяженность Fibre Channel шины без потери производительности составит несколько километров при использовании одномодовых оптических кабелей, и несколько сотен метров при многомодовом оптоволокне. Применение кабельных связей различной модности в одной сетевой ветке значительно поднимает стоимость всего проекта. Так как в этом случае потребуется приобрести специальные конвертеры, цена которых колеблется в районе 3000 USD за две штуки. Скорость информационного потока для одномодовой оптики ограничена двумя гигабитами в секунду.

В ряде мест вполне обоснованно применить для Fibre Channel шины и обычные медные кабели, однако это снижает интенсивность информационного обмена до 1 Гбит/сек. При больших протяженностях сети, либо для обеспечения достаточной «ширины» информационного потока техническая реализация шины происходит на оптоволоконных линиях связи 50/125 мкм или 62,5/125 мкм. Для обеспечения надежного стыка отдельных участков оптоволокна между собой применяются LC и SC разветвители. Такой подход придает Fibre Channel шине максимальное сходство с компьютерной сетью.

При вариантах «холодного» резервирования резервное оборудование находится в выключенном состоянии и включается только при подключении резерва в работу. До включения резервного оборудования его ресурс не расходуется, и «холодное» резервирование дает самую большую ВБР.

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

В случае «горячего» резервирования все резервные элементы ЦВМ включены и готовы сразу после команды включиться в работу. Это может обеспечить меньшее время переключения на резерв. Однако ресурс включенной резервной «горячей» аппаратуры расходуется и достижимая ВБР в этом методе меньше, чем в случае «холодного» резервирования. Время переключения на резерв – важный параметр, и допустимые его значения определяются конкретной прикладной задачей.

Для системы дублированной замещением с холодным резервом ВБР равна:

Данное приближение справедливо для ВБР . Использование дублирования с холодным замещением в нашем примере ЦВМ из 100 БИС с

на каждую ВБР за один год непрерывной работы будет равна

Рдуб.х = 1 – 0,01 = 0,99. Вместо 0.9 для нерезервированной системы.

Таким образом, простое дублирование ЦВМ приводит значение её ВБР в желаемые рамки.

Для системы троированной замещением с холодным резервом ВБР равна:

Ртр.х.= 0,995

Для системы дублированной замещением с горячим резервом ВБР равна:

И для нашего примера ЦВМ будет иметь значение ВБР

Рдб.г.= 0,99

Для системы троированной замещением с горячим резервом ВБР равна:

На графике приведены изменения Р(t) для трех случаев:

1) нерезервированная система

2) система дублированная с холодным резервом

3) система дублированная с горячим резервом

Горячее резервирование троированием с восстанавливающими органами (с мажоритарными элементами).

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

Мажоритарный элемент – логическое устройство, работающее по большинству. Если у него на входе 011,110,101,111 ,то на выходе у него1. Если у него на входе 001,010,100,000, то на выходе у него 0.

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

Система работоспособна, когда или все каналы работоспособны, или два из трех любых (таких сочетаний три) каналов работоспособны.

Здесь Р1 – ВБР каждого канала троированной системы.

Данная схема хороша не своей высокой ВБР (ВБР у систем с холодным и горячим резервированием замещением выше), а тем, что функции контроля и подключения резерва выполняются одновременно и автоматически на уровне МЭ. Специализированный мажоритарный контроль идет побитно над результатом каждой машинной операции. Здесь сами МЭ не резервированы и это недостаток примененной схемы.

В ЦВМ, резервированных по схеме троирования с мажоритарными органами, мажорированию подвергаются все разряды (поразрядно) передаваемого по шине данных числа, выбираемого из памяти или записываемого в память числа и т.п. По данным нашего примера ВБР ЦВМ с одним мажоритарным органом после выходного регистра имеет значение. Ртр.мж = 0,972

Сравнительные характеристики различных схем резервирования по ВБР, по времени перехода на резерв.

Изменение ВБР представлены в относительном времени . Это удобно, так как графики справедливы для любого . Здесь –

интенсивность отказов системы Для последовательной надежностной схемы.

Интенсивность отказа элементов, составляющих систему.

Красным цветом отмечено изменение ВБР по t для нерезервированной системы.

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

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

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

Наряду с этим широкое проникновение этих технологий в производство имеет оборотную сторону. Усиливается зависимость бизнеса от них. Любой компьютерный сбой приводит к простою одного или многих работников. В это время они не выполняют свою работу, следовательно, не зарабатывают прибыль. Не заработанная прибыль - это прямые убытки.

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

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

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

Основными преимуществами предлагаемых нами решений являются:

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

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

∙ Минимальное время простоя — отказы элементов серверов практически никак не влияют на производительность и целостность данных.

Виды резервирования

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

∙ Полная защита информации — данные не теряются даже в случае отказа одного из узлов.

∙ Открытая архитектура — все компоненты системы абсолютно стандартны, применение специальных аппаратных средств, модифицированных или специально написанных драйверов устройств не требуется.

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

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

Мы готовы предоставить дополнительную информацию и провести демонстрацию данных технологий.

Резервирование в электроснабжении

2.4.1 .Виды резервирования

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

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

Если при последовательном соединении элементов общая надежность системы (т.е. вероятность безотказной работы) ниже надежности самого ненадежного элемента, то при резервировании общая надежность системы может быть выше надежности самого надежного элемента.

Резервирование осуществляется путем введения избыточности. В зависимости от природы последней резервирование бывает:

Структурное (аппаратное);

Информационное;

Временное.

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

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

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

Существуют два метода повышения надежности систем путем структурного резервирования:

1) общее резервирование, при котором резервируется система в целом;

2) раздельное (поэлементное) резервирование, при котором резервируются отдельные части (элементы) системы.

Схемы общего и раздельного структурного резервирования представлены соответственно на рис. 2.6. и 2.7., где n — число последовательных элементов в цепи, m – число резервных цепей (при общем резервировании) или резервных элементов для каждого основного (при раздельном резервировании).

При m = 1 имеет место дублирование, а при m =2 – троирование. Обычно стремятся по возможности применять раздельное резервирование, т.к. при этом выигрыш в надежности часто достигается значительно меньшими затратами, чем при общем резервировании.

В зависимости от способа включения резервных элементов различают постоянное резервирование, резервирование замещением и скользящее резервирование.

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

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

Включение резервного оборудования замещением. Холодное и горячее резервирование.

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

Оба вида резервирования (постоянное и замещением) имеют свои преимущества и недостатки.

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

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

В зависимости от режима работы резервных элементов различают нагруженный (горячий) и ненагруженный (холодный) резерв.

Нагруженный (горячий) резерв в энергетике называют также вращающимся или включенным. В данном режиме резервный элемент находится в том же режиме, что и основной. Ресурс резервных элементов начинает расходоваться с момента включения в работу всей системы и вероятность безотказной работы резервных элементов в этом случае не зависит от того, в какой момент времени они включаются в работу.

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

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

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

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

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

⇐ Предыдущая13141516171819202122Следующая ⇒

Похожая информация:

Поиск на сайте:

В практике построения высокодоступных систем, прежде всего IT, существует понятие “единой точки отказа” (SPOF, Single Point Of Failure). Любая система высокой доступности данных стремится не иметь в своей архитектуре узла, линии связи или объекта, отказ которого может вывести из строя всю систему, или вызвать недоступность данных.

Все это так. Однако я обратил внимание, что в последнее время, в особенности в IT-шной среде возникло своеобразное “фетиширование” вот этого вот “отсутствия единой точки отказа”. Широко распространилось мнение, что “отсутствие единой точки отказа” это синоним “хорошо” и “система правильная ”, а ее присутствие – “плохо” и “система неправильная ”. �?

холодный резерв

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

Дело в том, что “отсутствие единой точки отказа” это “инструмент” для достижения высокой доступности, но не “цель”. “No SPOF” это одно из средств достижения доступности, но не сама доступность как таковая, средство, одно из, а не цель, часто необходимое, но не достаточное условие.

Что же, в таком случае, на самом деле определяет годность решения?

Мне представляется, что это удовлетворение требованиям по RPO/RTO для данной конкретной бизнес-задачи.

Термины RPO/RTO хорошо известны специалистам в области защиты данных и резервного копирования. RPO, Return Point Objective – это “точка доступности данных”, в случае их потери. RTO, Return Time Objective – это время, которое неоьходимо системе для восстановления своей работы, и возобновления обслуживания.

Например, если вы делаете резервное копирование вашей базы данных раз в сутки по вечерам, после окончания рабочего дня, в 21:00, то RPO для вашей системы будет 21:00 вечера предыдущего дня, то есть момент начала создания резервной копии.

Допустим, вы потеряли данные, восстановили их из бэкапа по состоянию на 21 час прошлого дня. Восстановление базы заняло 40 минут. Если у вас работает база данных, то вам еще надо актуализировать ее состояние из archive logs, накатив изменения, записанные с 21:00 по текущее время. Допустим, это заняло 15 минут. �?того, RTO, в вашем случае – 55 минут.

Плохо это или хорошо? Невозможно ответить с точки зрения IT. Ответ должен дать бизнес, которому вы служите. Для какой-то задачи даже 10 минут простоя это много. Какая-то вполне готова подождать пару часов, а какие-то задачи вполне могут и сутки постоять, ничего страшного не случится. Падение биржи NYSE может быть чревато паникой в масштабах глобальной экономики. Падение сети обслуживания банкоматов крупного банка, который за 10 минут периода простоя мог бы обработать десятки тысяч обращений “физиков”, это еще не паника, но все еще очень неприятно. А хостинг домашних страничек вполне может и сутки полежать с сообщением “�?звините, ведутся работы”, в лучшем случае выплатив клиентам неустойку за сутки простоя.

Разумеется, бизнес будет требовать нулевого RPO/RTO, это всегда так, они всегда это требуют. 🙂 Однако следует помнить, что все стоит денег, и каждое улучшение ситуации с временем недоступности стоит денег, причем часто растет по экспоненте, каждое следующее улучшение этих параметров обойдется бизнесу все дороже и дороже.

Поэтому, как правило, бизнес и IT обычно приходят к некоему компромиссу. Компромисс этот, как правило, сегментирован по задачам. Но в конечном счете бизнес и IT, совместно вырабатывают какие-то требования по RPO/RTO.

�? система, которая выполняет эти требования, система, удовлетворяющая этим требованиям бизнеса, за примелемые для бизнеса деньги – это хорошая система . Система, которая не удовлетворяет им – плохая .

Обратите внимание, что в моем опредении “плохой” и “хорошей” системы я не использовал понятие “отсутствия единой точки отказа” вовсе.

Может ли быть хорошей, то есть удовлетворять требованиям бизнеса по RPO/RTO, система с наличием “единой точки отказа”? Да запросто. Если период восстановления работоспособности системы укладывается в заданные рамки – да пусть сколько угодно там будет точек отказа. В особенности, если ликвидация в решении всех “единых точек отказа” экономически нецелесообразна, потому что чрезмерно дорога для решаемой бизнесом задачи.

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

В надежности нет “волшебной пули”, как нет и абсолютной надежности. �? наличие или отсутствие “единой точки отказа” в вашей части IT-системы может никак не отражаться на надежности бизнес-системы в целом. Всегда следует смотреть глубже, и задаваться целью, выполняются ли требования по RPO/RTO, необходимые бизнесу, и сколько это стоит. �? можно ли за те же деньги, или дешевле, найти решение, улучшающее этот показатель, и каким образом.

А не просто фетишировать на один из множества инструментов для достижения этой цели.

Метки: RPO, RPO/RTO, RTO, SPOF
Рубрика: justread | Комментариев нет

Резервирование дисков и каналов

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

OS NetWare 386 может резервировать целиком каналы, при этом используются два контроллера, к которым соответственно подключены два диска. Для питания этих контроллеров и дисков используются два блока питания.

Горячее резервирование серверов

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

Относительно недавно фирма Novell разработала сетевую OS NetWare System Fault Tolerance Level III (SFT III) версии 3.11. Эта OS обеспечивает горячее резервирование серверов.

Система NetWare SFT III состоит из двух серверов, соединенных между собой скоростной линией связи, с использованием специальных адаптеров MSL (Mirrored Server Link).Эти адаптеры могут соединяться коаксиальным кабелем длиной до 33 метров или оптоволоконным кабелем длиной до 4 километров.

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

Глава II. Техническое построение локальной сети

Постановка задачи

Целью курсовой является организация локальной сети и выход в Интернет в жилом доме

Для решения поставленной цели в курсовой работе решаются следующие задачи:

· Выбор топологии и кабельной системы сети;

· Выбор сетевого оборудования;

· Выбор программного обеспечения.

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

Построение сети

Для решения первой задачи мною была выбрана топология «Звезда» так как:

Традиционно считается, что локальные сети должны строиться по топологии "звезда", а кольцевая архитектура присуща серьезным телекоммуникационным системам на основе SDH/ATM (это очень эффективное средство повышения надежности в телефонии, где несколько АТС могут продолжать работать независимо от вышедшего из строя узла).

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

Горячий резерв

При использовании "кольца" в случае выхода из строя какого-либо узла (или части кабельной системы) работоспособность сети в целом сохраняется.

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

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

Для решения задачи выбора кабельной системы сети мною был выбран кабель витая пара категории «cat5e» так как:

Для абонентской системы здания оптимальным выбором служит витая пара категории 5е. Она позволяет передавать данные со скоростью 100мбит/c, удобна в прокладке, обладает достаточно низкой стоимостью и отвечает всем требованиям по надёжности, предъявляемым к абонентской системе.

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

Для решения задачи выбора сетевого оборудования, мною были выбраны 2 коммутатора D-Link DES-3028, так как управляемые коммутаторы второго уровня серии DES-3028 представляют собой наиболее эффективное решение в категории управляемых сетевых коммутаторов начального уровня. Обладая богатым функционалом, эти коммутаторы предоставляют недорогое решение по созданию безопасной и эффективной сети отделов предприятий малого и среднего бизнеса, а также промышленных предприятий. Также эта серия является оптимальным по соотношению «цена/функционал» решением уровня доступа сети провайдера услуг. Отличительными функциями данного коммутатора являются высокая плотность портов, 4 гигабитных порта Uplink, небольшой шаг изменения настроек для управления полосой пропускания и улучшенное сетевое управление. Эти коммутаторы позволяют оптимизировать сеть как по функционалу, так и по стоимостным характеристикам.

Главный и идинственный сервер в сети должен обеспечивать:

· WEB — сервер

· Файловое хранилище

· P2P – трекер

· Выступать посредником между серверами интернет-провайдера и локальной сетью

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

· Процессор: Core 2 Quad Q9650

· Память: 8Gb DDR II

· 2x 1,5Tb HDD обьедененых в RAID 0

В качестве сетевой ОС была выбрана Ubuntu Server x64, так как эта ОС имеет ряд огромных плюсов, такких как:

· Бесплатность в отличии, например, от Windows Server

· Гибкость конфигурации

· Наличие всего необходимого софта в базовом пакете

· Поддердка практически всего оборудования

· Регулярные обновления и наличие русскоязычного сайта поддержки

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

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

26.5.1. Обзор на уровне пользователя

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

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

Команды манипуляции данными (DML) - INSERT , UPDATE , DELETE , COPY FROM , TRUNCATE . Следует отметить, что нет разрешённых действий, которые приводили бы к срабатыванию триггера во время исполнения на резервном сервере. Это ограничение так же касается и временных таблиц, так как строки таблицы не могут быть прочитаны или записаны без обращения к ID транзакции, что в настоящее время не возможно в среде горячего резерва.

Команды определения данных (DDL) - CREATE , DROP , ALTER , COMMENT . Эти ограничения так же относятся и к временным таблицам, так как операции могут потребовать обновления таблиц системных каталогов.

SELECT ... FOR SHARE | UPDATE , так как блокировка строки не может быть проведена без обновления соответствующих файлов данных.

Правила для выражений SELECT , которые приводят к выполнению команд DML.

LOCK которая явно требует режим более строгий чем ROW EXCLUSIVE MODE .

LOCK в короткой форме с умолчаниями, так как требует ACCESS EXCLUSIVE MODE .

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

• BEGIN READ WRITE , START TRANSACTION READ WRITE

  SET TRANSACTION READ WRITE , SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE

  SET transaction_read_only = off

Команды двухфазной фиксации - PREPARE TRANSACTION , COMMIT PREPARED , ROLLBACK PREPARED , так как даже транзакции только для чтения нуждаются в записи в WAL на подготовительной фазе (первая фаза двухфазной фиксации).

Обновление последовательностей - nextval() , setval()

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

В режиме горячего резерва параметр transaction_read_only всегда имеет значение true и изменить его нельзя. Но если не пытаться модифицировать содержимое БД, подключение к серверу в этом режиме не отличается от подключений к обычным базам данных. При отработке отказа или переключении ролей база данных переходит в обычный режим работы. Когда сервер меняет режим работы, установленные сеансы остаются подключёнными. После выхода из режима горячего резерва становится возможным запускать пишущие транзакции (даже в сеансах, начатых ещё в режиме горячего резерва).

Пользователи могут узнать о нахождении сессии в режиме только для чтения с помощью команды SHOW transaction_read_only . Кроме того, набор функций (Таблица 9.80) позволяет пользователям получить доступ к информации о резервном сервере. Это позволяет создавать программы, учитывающие текущий статус базы данных. Такой режим может быть полезен для мониторинга процесса восстановления или для написания комплексного восстановления для особенных случаев.

26.5.2. Обработка конфликтов запросов

Ведущий и резервный серверы связаны между собой многими слабыми связями. События на ведущем сервере оказывают влияние на резервный. В результате имеется потенциальная возможность отрицательного влияния или конфликта между ними. Наиболее простой для понимания конфликт - быстродействие: если на ведущем происходит загрузка очень большого объёма данных, то происходит создание соответствующего потока записей WAL на резервный сервер. Таким образом, запросы на резервном конкурируют за системные ресурсы, например, ввод-вывод.

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

Установка эксклюзивной блокировки на ведущем сервере, как с помощью явной команды LOCK , так и при различных DDL , что приводит к конфликту доступа к таблицам на резервном.

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

Удаление базы данных на ведущем сервере конфликтует с сессиями, подключёнными к этой БД на резервном.

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

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

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

Примером такой проблемы может быть ситуация: администратор на ведущем сервере выполнил команду DROP TABLE для таблицы, которая сейчас участвует в запросе на резервном. Понятно, что этот запрос нельзя будет выполнять дальше, если команда DROP TABLE применится на резервном. Если бы этот запрос выполнялся на ведущем, команда DROP TABLE ждала бы его окончания. Но когда на ведущем выполняется только команда DROP TABLE , ведущий сервер не знает, какие запросы выполняются на резервном, поэтому он не может ждать завершения подобных запросов. Поэтому если записи WAL с изменением прибудут на резервный сервер, когда запрос будет продолжать выполняться, возникнет конфликт. В этом случае резервный сервер должен либо задержать применение этих записей WAL (и всех остальных, следующих за ними), либо отменить конфликтующий запрос, чтобы можно было применить DROP TABLE .

Если конфликтный запрос короткий, обычно желательно разрешить ему завершиться, ненадолго задержав применение записей WAL, но слишком большая задержка в применении WAL обычно нежелательна. Поэтому механизм отмены имеет параметры max_standby_archive_delay и max_standby_streaming_delay , которые определяют максимально допустимое время задержки применения WAL. Конфликтующие запросы будут отменены, если они длятся дольше допустимого времени задержки применения очередных записей WAL. Два параметра существуют для того, чтобы можно было задать разные значения для чтения записей WAL из архива (то есть при начальном восстановлении из базовой копии либо при «навёрстывании » ведущего сервера в случае большого отставания) и для получения записей WAL при потоковой репликации.

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

В случае, если задержка, определённая max_standby_archive_delay или max_standby_streaming_delay будет превышена, конфликтующий запрос будет отменён. Обычно это выражается в виде ошибки отмены, но в случае проигрывания команды DROP DATABASE обрывается вся конфликтная сессия. Так же, если конфликт произошел при блокировке, вызванной транзакцией в состоянии IDLE, конфликтная сессия разрывается (это поведение может изменить в будущем).

Отменённые запросы могут быть немедленно повторены (конечно после старта новой транзакции). Так как причина отмены зависит от природы проигрываемых записей WAL, запрос, который был отменён, может быть успешно выполнен вновь.

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

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

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

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

В случае, если количество отменённых запросов на резервном сервере получается неприемлемым, существует ряд дополнительных возможностей. Первая возможность - установить параметр hot_standby_feedback , который не даёт команде VACUUM удалять записи, ставшие недействительными недавно, что предотвращает конфликты очистки. При этом следует учесть, что это вызывает задержку очистки мёртвых строк на ведущем, что может привести к нежелательному распуханию таблицы. Тем не менее, в итоге ситуация будет не хуже, чем если бы запросы к резервному серверу исполнялись непосредственно на ведущем, но при этом сохранится положительный эффект от разделения нагрузки. В случае, когда соединение резервных серверов с ведущим часто разрывается, следует скорректировать период, в течение которого обратная связь через hot_standby_feedback не обеспечивается. Например, следует подумать об увеличении max_standby_archive_delay , чтобы запросы отменялись не сразу при конфликтах с архивом WAL в период разъединения. Также может иметь смысл увеличить max_standby_streaming_delay для предотвращения быстрой отмены запросов из-за полученных записей WAL после восстановления соединения.

Другая возможность - увеличение vacuum_defer_cleanup_age на ведущем сервере таким образом, чтобы мёртвые записи не очищались бы так быстро, как при обычном режиме работы. Это даёт запросам на резервном сервере больше времени на выполнение, прежде чем они могут быть отменены, без увеличения задержки max_standby_streaming_delay . Тем не менее при таком подходе очень трудно обеспечить какое-то определённое окно по времени, так как vacuum_defer_cleanup_age измеряется в количестве транзакций, выполняемых на ведущем сервере.

Количество отменённых запросов и причины отмены можно просмотреть через системное представление pg_stat_database_conflicts на резервном сервере. Системное представление pg_stat_database так же содержит итоговую информацию.

26.5.3. Обзор административной части

Если в файле postgresql.conf для параметра hot_standby задано значение on (по умолчанию) и существует файл recovery.conf , сервер запустится в режиме горячего резерва. Однако может пройти некоторое время, прежде чем к нему можно будет подключиться, так как он не будет принимать подключения, пока не произведёт восстановление до согласованного состояния, подходящего для выполнения запросов. (Информация о согласованности состояния записывается на ведущем сервере в контрольной точке.) В течение этого периода клиенты при попытке подключения будут получать сообщение об ошибке. Убедиться, что сервер включился в работу, можно либо повторяя попытки подключения из приложения до успешного подключения, либо дождавшись появления в журналах сервера этих сообщений:

LOG: entering standby mode ... then some time later ... LOG: consistent recovery state reached LOG: database system is ready to accept read only connections

Включить горячий резерв нельзя, если WAL был записан в период, когда на ведущем сервере параметр wal_level имел значение не replica и не logical . Достижение согласованного состояния также может быть отсрочено, если имеют место оба этих условия:

Пишущая транзакция имеет более 64 подтранзакций

Очень длительные пишущие транзакции

Если вы применяете файловую репликацию журналов («тёплый резерв»), возможно, придётся ожидать прибытия следующего файла WAL (максимальное время ожидания задаётся параметром archive_timeout на ведущем сервере).

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

• max_prepared_transactions

  max_locks_per_transaction

  max_worker_processes

Очень важно для администратора выбрать подходящие значения для max_standby_archive_delay и max_standby_streaming_delay . Оптимальное значение зависит от приоритетов. Например, если основное назначение сервера - обеспечение высокой степени доступности, то следует установить короткий период, возможно даже нулевой, хотя это очень жёсткий вариант. Если резервный сервер планируется как дополнительный сервер для аналитических запросов, то приемлемой будет максимальная задержка в несколько часов или даже -1, что означает бесконечное ожидание окончания запроса.

Вспомогательные биты статуса транзакций, записанные на ведущем, не попадают в WAL, так что они, скорее всего, будут перезаписаны на нём при работе с данными. Таким образом, резервный сервер будет производить запись на диск, даже если все пользователи только читают данные, ничего не меняя. Кроме того, пользователи будут записывать временные файлы при сортировке больших объёмов и обновлять файлы кеша. Поэтому в режиме горячего резерва ни одна часть базы данных фактически не работает в режиме «только чтение». Следует отметить, что также возможно выполнить запись в удалённую базу данных с помощью модуля dblink и другие операции вне базы данных с применением PL-функций, несмотря на то, что транзакции по-прежнему смогут только читать данные.

Следующие типы административных команд недоступны в течение режима восстановления:

Команды определения данных (DDL) - например: CREATE INDEX

Команды выдачи привилегий и назначения владельца - GRANT , REVOKE , REASSIGN

Команды обслуживания - ANALYZE , VACUUM , CLUSTER , REINDEX

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

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

Функции pg_cancel_backend() и pg_terminate_backend() работают на стороне пользователя, но не для процесса запуска, который обеспечивает восстановление. Представление pg_stat_activity не показывает восстанавливаемые транзакции как активные. Поэтому представление pg_prepared_xacts всегда пусто в ходе восстановления. Если требуется разобрать сомнительные подготовленные транзакции, следует обратиться к pg_prepared_xacts на ведущем и выполнить команды для разбора транзакций там либо разобрать их по окончании восстановления.

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

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

Команды управления файлами WAL, например pg_start_backup , pg_switch_wal и т. д. не будут работать во время восстановления.

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

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

Системы репликации на базе триггеров, подобные Slony , Londiste и Bucardo не могут запускаться на резервном сервере вовсе, хотя они превосходно работают на ведущем до тех пор, пока не будет подана команда не пересылать изменения на резервный. Проигрывание WAL не основано на триггерах, поэтому поток WAL нельзя транслировать с резервного сервера в другую систему, которая требует дополнительной записи в БД или работает на основе триггеров.

Новые OID не могут быть выданы, хотя, например генераторы UUID смогут работать, если они не пытаются записывать новое состояние в базу данных.

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

Команда DROP TABLESPACE может быть выполнена только если табличное пространство пусто. Некоторые пользователи резервного сервера могут активно использовать табличное пространство через параметр temp_tablespaces . Если имеются временные файлы в табличных пространствах, все активные запросы отменяются для обеспечения удаления временных файлов, затем табличное пространство может быть удалено и продолжено проигрывание WAL.

Выполнение команды DROP DATABASE или ALTER DATABASE ... SET TABLESPACE на ведущем сервере приводит к созданию записи в WAL, которая вызывает принудительное отключение всех пользователей, подключённых к этой базе данных на резервном. Это происходит немедленно, вне зависимости от значения max_standby_streaming_delay . Следует отметить, что команда ALTER DATABASE ... RENAME не приводит к отключению пользователей, так что обычно она действует незаметно, хотя в некоторых случаях возможны сбои программ, которые зависят от имени базы данных.

Если вы в обычном режиме (не в режиме восстановления) выполните DROP USER или DROP ROLE для роли с возможностью подключения, в момент, когда этот пользователь подключён, на данном пользователе это никак не отразится - он останется подключённым. Однако переподключиться он уже не сможет. Это же поведение действует в режиме восстановления - если выполнить DROP USER на ведущем сервере, пользователь не будет отключён от резервного.

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

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

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

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

Уровень изоляции транзакции Serializable в настоящее время недоступен в горячем резерве. (За подробностями обратитесь к Подразделу 13.2.3 и Подразделу 13.4.1) Попытка выставить для транзакции такой уровень изоляции в режиме горячего резерва вызовет ошибку.