Vss что такое – Секреты службы теневого копирования » Статьи о Microsoft Windows. Установка, администрирование, ускорение и оптимизация Microsoft Windows 7, Windows 8, Windows XP, и Windows 10

Содержание

Перерегистрация компонентов VSS (Volume Shadow Copy Service) в Windows Server

Большинство решений для резервного копирования данных под Windows в том или ином виде используют возможности службы теневых копий (VSS — Volume Shadow Copy Service) для создания копий данных приложений или сервисов. В некоторых случаях, служба VSS или один из ее модулей записей начинают работать некорректно, в результате чего не удается выполнить нормальную процедуру резервное копирования данных. Я сталкивался с такой ошибкой на Exchange, MSSQL и Hyper-V серверах. Для быстрого восстановления службы VSS и ее компонентов я использую следующую инструкцию.

Чтобы определить сбойный модуль VSS, выведем список зарегистрированных в системе модулей записи VSS (Writers) с помощью команды vssadmin.

vssadmin list writers

В списке компонентов ищем те, которые находятся в состоянии Failed (для нормально работающих компонентов статус должен быть State: [1] Stable)

Writer name: 'Microsoft Exchange Writer'
Writer Id: {76fe1ac4-6ded-4f4b-8f17-fd23f8ddcfb7}
Writer Instance Id: {31b56ab0-9588-412f-ae7b-cdc375347158}
State: [7] Failed
Last error: Retryable error

Как вы видите, в нашем случае модуль записи Microsoft Exchange Writer находится в сбойном состоянии (State: [8] Failed), поэтому резервное копирование Exchange выполнить не удастся. Как правило, чтобы исправить состояние такого компонента, достаточно перезагрузить сервер (что не всегда возможно по производственным причинам).

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

VSS WriterИмя службы Полное имя службы
ASR WriterVSSVolume Shadow Copy
BITS WriterBITSBackground Intelligent Transfer Service
Certificate AuthorityCertSvcActive Directory Certificate Services
COM+ REGDB WriterVSSVolume Shadow Copy
DFS Replication service writerDFSRDFS Replication
DHCP Jet WriterDHCPServerDHCP Server
FRS WriterNtFrsFile Replication
FSRM writersrmsvcFile Server Resource Manager
IIS Config WriterAppHostSvcApplication Host Helper Service
IIS Metabase WriterIISADMINIIS Admin Service
Microsoft Exchange Replica WriterMSExchangeReplMicrosoft Exchange Replication Service
Microsoft Exchange WriterMSExchangeISMicrosoft Exchange Information Store
Microsoft Hyper-V VSS WritervmmsHyper-V Virtual Machine Management
MSMQ Writer (MSMQ)MSMQMessage Queuing
MSSearch Service WriterWSearchWindows Search
NPS VSS WriterEventSystemCOM+ Event System
NTDSNTDSActive Directory Domain Services
OSearch VSS WriterOSearchOffice SharePoint Server Search
OSearch24 VSS WriterOSearch24SharePoint Server Search 14
Registry WriterVSSVolume Shadow Copy
Shadow Copy Optimization WriterVSSVolume Shadow Copy
SMS WriterSMS_SITE_VSS_WRITERSMS_SITE_VSS_WRITER
SPSearch VSS WriterSPSearchWindows SharePoint Services Search
SPSearch5 VSS WriterSPSearch5SharePoint Foundation Search V4
SqlServerWriterSQLWriterSQL Server VSS Writer
System WriterCryptSvcCryptographic Services
TermServLicensingTermServLicensingRemote Desktop Licensing
WDS VSS WriterWDSServerWindows Deployment Services Server
WIDWriterWIDWriterWindows Internal Database VSS Writer
WINS Jet WriterWINSWindows Internet Name Service (WINS)
WMI WriterWinmgmtWindows Management Instrumentation

Еще раз выполните команду

vssadmin list writers

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

Перейдите в каталог:

cd c:\windows\system32

Остановите службы Volume Shadow Copy и Microsoft Software Shadow Copy Provider

Net Stop VSS
Net Stop SWPRV

Перерегистрируйте компоненты VSS:

regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll
vssvc /register

Теперь осталось запустить остановленные службы:
Net Start SWPRV
Net Start VSS

Проверьте, пропала ли ошибка у проблемного модуля записи VSS.

Данный метод перезапуска и перерегистрации компонентов VSS эффективен, как на Windows Server 2008 / 2012/ R2, так и на Windows Server 2016.

winitpro.ru

Секреты службы теневого копирования » Статьи о Microsoft Windows. Установка, администрирование, ускорение и оптимизация Microsoft Windows 7, Windows 8, Windows XP, и Windows 10

Служба теневого копирования Volume Shadow Copy Service (VSS) обеспечивает две функции, которые помогут администратору сэкономить время и избавиться от лишних хлопот. Первая из них — моментальный снимок (краткосрочная резервная копия всех файлов тома NTFS). Благодаря моментальному снимку или теневой копии пользователи могут самостоятельно восстановить случайно удаленный файл или исправить последствия ошибочного выбора команды Save («Сохранить») вместо Save As («Сохранить как»). VSS не предназначен для замены текущей стратегии архивирования, как будет показано ниже. Вторая важная возможность VSS — архивирование файлов, открытых или блокированных таким приложением, как Microsoft SQL Server или Microsoft Exchange.

VSS создает теневые копии по расписанию или по требованию. Использовать службу VSS в Windows 2003 и для системного восстановления Vista просто. В данной статье показано, как настроить резервные копии с использованием VSS в Windows 2003 и преобразовать базовые диски в динамические, не повредив теневые копии. В процессе применения VSS администратору могут пригодиться рекомендации, приведенные во врезке «Пять советов по VSS».

Принципы работы VSS

Служба VSS создает моментальный снимок всех файлов на томе NTFS или томе-источнике. Теневые копии хранятся в области, именуемой кэшем теневых копий. Том, на котором находится кэш теневых копий, называется томом хранения теневой копии. Кэш теневых копий, как правило, невидим для пользователей, так как находится в скрытой системной папке System Volume Information.

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

Службу VSS можно активизировать только на томах NTFS. Нельзя ввести или исключить конкретные файлы или папки — только «все или ничего». Данные на смонтированных томах не включаются в теневую копию на родительском томе. Однако можно разрешить теневые копии на самих монтированных томах. В теневых копиях сохраняются как шифрование, так и разрешения NTFS, что может привести к проблемам при восстановлении файла.




Активизация VSS

Чтобы активизировать службу VSS, следует выбрать My Computer, затем щелкнуть правой кнопкой мыши на томе, на котором предстоит включить VSS, и выбрать пункт Properties. На странице Properties требуется щелкнуть на вкладке Shadow Copies. Если это уже сделано, необходимо решить, нужно ли сохранить кэш теневых копий на другом томе другого диска.

Затем выделите том-источник и щелкните на кнопке Settings. В диалоговом окне Settings можно выбрать другой том для хранения теневой копии, как показано на экране 1. Можно изменить размер области хранения и расписание (щелкнув на кнопке Schedule), если не подходит готовое расписание. По умолчанию моментальные снимки формируются с понедельника до пятницы в 7 часов утра и в полдень. Моментальные снимки следует создавать по необходимости, делать это каждый час не нужно.

Завершив настройку параметров, щелкните на кнопке OK. На странице Properties требуется щелкнуть на кнопке Enable, чтобы активизировать теневые копии на данном томе. Последует запрос об использовании расписания и настроек по умолчанию; необходимо принять это предложение и щелкнуть на кнопке Yes, а затем вновь на кнопке OK.
Сторонникам утилит командной строки полезно освоить настройку VSS с использованием Vssadmin и Schtasks вместо графического интерфейса. С помощью Vssadmin можно создавать, удалять и изменять размеры теневых копий, наряду с другими операциями. Schtasks применяется для создания, редактирования и удаления назначенных задач.

Требования к дисковому пространству. При активизации VSS немедленно выделяется 100 Мбайт пространства на диске, и VSS может занимать до 10% размера жесткого диска. В моментальных снимках отражаются только изменения по сравнению с предшествующим моментальным снимком, поэтому для их хранения требуется меньше места, чем может показаться на первый взгляд. Однако в кэше теневых копий может храниться только 64 копии. Если не хватит дискового пространства или будет создан 65-й моментальный снимок, то самый старый моментальный снимок удаляется, чтобы освободить место для нового. Из-за избыточности при создании моментальных снимков рекомендуется активизировать VSS только на томах, на которых хранятся пользовательские данные или есть возможность архивировать открытые файлы.

Использование теневых копий Windows 2003

Чтобы обеспечить доступ клиентских компьютеров к предыдущим версиям файлов, необходимо приложение Previous Versions Client, поставляемое вместе с Vista и Windows 2003. Previous Versions Client можно установить и на Windows XP Professional SP1 (файл twcli32.msi находится в папке %Windir%\System32\Clients\Twclient\X86 на компакт-диске Windows 2003), и на Windows 2000 (нужно загрузить соответствующую версию из Web-узла Microsoft). Чтобы установить клиентскую программу на компьютеры пользователей, следует дважды щелкнуть на файле для запуска установки либо развернуть его через групповую политику или Microsoft Systems Management Server (SMS).

Теневые копии предназначены для использования с Common Internet File System (CIFS), расширенным вариантом протокола Server Message Block, поэтому для доступа к предшествующим версиям файла или папки на сервере нужно подключаться через общую папку. Даже после регистрации на сервере необходимо использовать путь Universal Naming Convention (UNC). Например, для доступа к старым версиям файла на сервере с именем UptownDC в общей папке Sales требуется щелкнуть на кнопке Start, выбрать пункт Run и ввести команду

\\Uptowndc\sales 

Щелкните на кнопке OK, а затем правой кнопкой мыши на нужном файле и выберите пункт Properties. На вкладке Previous Versions перечислены моментальные снимки и показаны дата и время их создания (см. экран 2). Здесь представлены три варианта действий: View, Copy и Restore. В режиме View копия файла открывается только для чтения; это удобно для выбора нужной копии. В режиме Restore документ, его разрешения NTFS и параметры шифрования восстанавливаются в первоначальном месте, а текущая версия перезаписывается. Более безопасный вариант — Copy, при котором файл копируется в новое место.

Если нужно восстановить удаленный файл, то очевидно, что нельзя щелкнуть правой кнопкой мыши на файле в общей папке и выбрать его свойства. В этом случае необходимо перейти на уровень папки. Вместо UNC-пути \\Uptowndc\Sales подключение выполняется к административному ресурсу диска C (на котором размещается папка Sales): \\Uptowndc\C$. Щелкните правой кнопкой мыши на папке Sales, выберите пункт Properties и щелкните на соответствующей кнопке, чтобы просмотреть, копировать или восстановить все содержимое папки. Если нужен лишь один файл, следует скопировать папку в новое место, затем щелкнуть правой кнопкой мыши на файле и работать с предыдущими версиями этого файла.

Vista и теневые копии

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

Заранее планируемая задача SR создает точки восстановления и активизируется только в том случае, если компьютер бездействовал не менее 10 минут и питается от сети переменного тока. Если по какой-то причине задача SR не запущена в назначенное время, она будет выполнена при первой возможности. Можно назначить точки восстановления и для других томов. Vista отводит до 15% пространства на жестком диске для хранения точек восстановления.

Чтобы настроить точки восстановления и управлять ими, щелкните Start, а затем щелкните правой кнопкой мыши Computer и выберите пункт Properties. В меню Tasks следует перейти к пункту System protection. Для доступа к System protection необходимы административные полномочия, поэтому при запросе от механизма контроля учетных записей щелкните на кнопке Continue.

На вкладке System Protection страницы System Properties (экран 3) можно вручную создать одноразовую точку восстановления: выберите том и щелкните Create, дайте имя точке восстановления и вновь щелкните Create. Процесс может занять несколько минут, в зависимости от размера тома, но после его завершения выдается подтверждение об успешном выполнении. Если создание точек восстановления для тома автоматизировано, Vista создает новую точку восстановления для тома каждый день и при запуске системы.

Доступ к предыдущим версиям файлов и папок в Vista происходит так же, как при доступе через общую папку Windows 2003 с клиента с установленным приложением Previous Versions Client. Но пользователи Vista могут обращаться к прошлым версиям файлов и папок локально. Достаточно открыть Windows Explorer, щелкнуть правой кнопкой мыши на файле или папке, выбрать пункт Properties, а затем щелкнуть на вкладке Previous Versions (экран 4). Варианты такие же, как у прошлых версий Previous Versions Client, и функционируют они аналогичным образом.

VSS и сети хранения данных

Еще одно важное достоинство VSS в Windows Server 2003 Enterprise Edition и Datacenter Edition — возможность быстро и просто копировать и перемещать данные в сети хранения данных SAN. VSS может создать теневую копию тома размером в несколько терабайтов, которую можно экспортировать из SAN и импортировать на сервер всего за несколько минут, очень быстро перемещая большие массивы данных. Каждый производитель систем хранения данных по-разному реализует эту функцию, поэтому за подробной информацией следует обратиться к поставщику.

Настройка конфигурации VSS

Для томов с VSS рекомендуется размер кластеров не менее 16 Кбайт. Записи VSS преобразуются в файлы 16-Кбайт блоками. На томах величиной от 2 до 4 Тбайт размер кластера по умолчанию — 4 Кбайт. Но при кластерах размером менее 16 Кбайт поставщик VSS не может определить, был ли файл дефрагментирован или изменен. Поэтому VSS обрабатывает дефрагментированный файл так же, как измененный, — генерирует новую теневую копию файла. После дефрагментации диска с малыми кластерами кэш теневых копий может очень быстро расти и перезаписывать существующие теневые копии. Дополнительную информацию об этом можно найти в статье Microsoft «Shadow copies may be lost when you defragment a volume» по адресу http://support.microsoft.com/kb/312067.

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

fsutil fsinfo ntfsinfo C:

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

Взаимодействие NTBackup и VSS

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

Утилита резервного копирования Windows 2003, NTBackup, использует VSS, чтобы обеспечить полноту и согласованность архивных копий. VSS взаимодействует с компонентом записи приложения, связанного с файлом. Компонент записи защищает данные приложения и предоставляет информацию, в частности, о местонахождении данных и методах архивации и восстановления. Приложения без компонента записи не могут взаимодействовать со службой VSS. В худшем случае администратор может попытаться восстановить важный файл и обнаружить, что его нет вообще: он никогда не архивировался, так как приложение не может взаимодействовать с VSS. В Windows 2003 существуют компоненты записи для AD и NTFS. Чтобы отыскать все доступные компоненты записи на сервере, нужно ввести команду

vssadmin list writers

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

Мониторинг функционирования VSS

Мониторинг теневых копий с использованием системного монитора в Windows 2003 поможет предупредить потенциальные неполадки, прежде чем они повлияют на пользователей. Например, системный монитор предупреждает, что пространство на диске, использованное для теневых копий, приближается к максимально допустимой величине. По умолчанию системный монитор не содержит объектов или счетчиков, которые отслеживают характеристики теневых копий, но администратор может ввести их самостоятельно. Инструкции по созданию счетчиков даны в статье Microsoft «Add counters to System Monitor», опубликованной по адресу http://technet2.microsoft.com/windowsserve…3.mspx?mfr=true.

С помощью утилиты Volperf (с ключом /install) из набора ресурсов Microsoft Windows Server 2003 Resource Kit можно дополнить системный монитор объектами теневого копирования и следующими счетчиками:

• % Disk Used by Diff Area File: процент пространства на диске, используемого всеми разностными файлами тома;
• Allocated Space (MB): пространство памяти (Мбайт), выделенное для конкретного тома;
• Maximum Space (MB): максимальное пространство (Мбайт), выделенное для тома хранения теневой копии;
• Nb of Diff Area Files: число разностных файлов;
• Nb of Shadow Copies: число теневых копий в кэше теневых копий;
• Size of Diff Area Files: общий размер разностных файлов для выбранного тома;
• Used Space (MB): величина пространства (Мбайт), использованного в томе хранения теневой копии

Преобразование базового диска в динамический и служба VSS

Иногда полезно добавить лишний аппаратный уровень отказоустойчивости, создав зеркальный набор. Зеркальные наборы можно строить только на динамических дисках, поэтому базовый диск необходимо преобразовать в динамический. В документации утверждается, что преобразование дисков из базовых в динамические не приводит к потере данных. Однако в документации ничего не говорится о том, что при неверном преобразовании могут быть удалены существующие теневые копии. Если том-источник и кэш теневых копий расположены на разных томах, то преобразование может оказаться сложной задачей. Дополнительные сведения о различиях между базовым и динамическим дисками описаны в статье «Диски для серверов Windows — базового или динамического типа», опубликованной в Windows IT Pro/RE № 1 за 2003 г.

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

Сценарий 1 — кэш теневых копий расположен не на загрузочном томе. Если кэш теневых копий находится не на загрузочном томе, то необходимо сначала размонтировать том-источник (том, для которого сделан моментальный снимок) с помощью утилиты командной строки Mountvol с параметром /P (/P демонтирует том). Затем следует преобразовать том, содержащий кэш теневых копий, в динамический том. С этого момента начинается отсчет времени: у администратора есть лишь 20 минут, чтобы смонтировать том-источник с использованием утилиты Mountvol или оснастки Disk Management консоли управления MMC. Если том-источник не будет смонтирован за 20 минут, то все теневые копии будут утеряны. Наконец, верните том-источник в оперативный режим и преобразуйте его в динамический том.

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

Выгодно конечному пользователю — выгодно администратору

Приятно, что компания Microsoft выпускает новые инструменты для восстановления работоспособности настольной операционной системы и для ИТ-специалистов, и для конечных пользователей. Чем меньше резервных магнитных лент приходится загружать администратору, тем проще ему работать, и точки восстановления Vista — шаг в правильном направлении. Кроме того, благодаря VSS у пользователей появляется возможность управлять процессом восстановления файлов. Но тщательное планирование и управление — обязательное условие полной реализации преимуществ службы VSS.

Пять советов по VSS

При реализации VSS или подготовке точек восстановления Vista рекомендуется делать следующее:

1…Прежде чем активизировать точки восстановления VSS, выберите место хранения теневых копий. Помните, что впоследствии переместить их нельзя.
2…Размещение VSS на системном или загрузочном томе — неудачное решение. Файлы операционной системы часто изменяются, поэтому число теневых копий на загрузочном томе обычно бывает большим.
3…Оптимальный размер кластера для VSS — 16 Кбайт.
4…При хранении кэша теневых копий на физическом диске, отличном от диска-источника, повышается быстродействие и отказоустойчивость.
5…Ни VSS, ни точки восстановления не могут заменить полноценное решение резервного копирования.

Автор: Ронда Лейфилд ([email protected]) — консультант и преподаватель
Источник: WindowsITpro



Оцените статью: Голосов 6

www.winblog.ru

Volume Shadow Copy Service (VSS) | Windows IT Pro/RE

Новая служба предоставляет дополнительные возможности для восстановления файлов.

Служба фонового копирования тома — Microsoft Volume Shadow Copy Service (VSS) — может оказаться очень полезной для резервирования и восстановления файлов. VSS, реализованная в Windows Server 2003, создает актуальную копию файлов, хранящихся в сетевых каталогах общего доступа, — даже в тех случаях, когда эти файлы открыты или заблокированы. Приложения могут продолжать записывать данные на дисковый том во время работы VSS, что избавляет от необходимости создавать резервную копию данных до начала или после окончания рабочего дня. Кроме того, возможность обратиться к резервной копии тома в любое время означает, что пользователь всегда может самостоятельно, не привлекая администратора, выполнить восстановление нужных файлов.

Настроить VSS несложно. Следует открыть контекстное меню тома, на котором находится сетевой ресурс, и выбрать Properties. Затем нужно перейти на вкладку Shadow Copies и указать том, для которого требуется создать резервную копию. Необходимо щелкнуть Enable для активизации фонового копирования всех каталогов общего доступа тома и создать первую резервную копию. На Экране 1 показана вкладка Shadow Copies с активизированной службой фонового копирования. На этой вкладке в секции Select a volume показано время следующего сеанса запуска фонового копирования, число совместно используемых ресурсов и место на диске, отведенное для копии. В секции Shadow copies of selected volume содержится список уже созданных копий для выбранного тома. Чтобы создать дополнительные копии, нужно щелкнуть Create Now. Остановить процедуру фонового копирования можно простым щелчком Disable, однако следует иметь в виду, что это действие приведет к удалению всех ранее созданных копий.


Экран 1. Вкладка Shadow Copies с активизированной службой фонового копирования.

Чтобы настроить остальные параметры VSS, необходимо щелкнуть Settings на вкладке Shadow Copies. Как показано на Экране 2, в окне Settings можно установить максимальный размер дискового пространства, отводимый для создаваемых в фоновом режиме копий. Требуется щелкнуть Schedule и установить время запуска VSS. По умолчанию VSS будет запускаться каждый рабочий день в 7 ч утра и в 12 ч дня. Щелкните Schedule, и в открывшемся окне появится действующее расписание работы процедуры создания резервных копий. Следует щелкнуть New и добавить к существующему списку новое задание, затем удалить ненужные процедуры копирования, а для дополнительной настройки задания щелкнуть Advanced. Хотя возможности настройки расписания выполнения задания весьма широки, желательно избегать запуска процедуры копирования чаще, чем один раз в час.


Экран 2. Установка размера дискового пространства для создаваемых в фоновом режиме копий

VSS позволяет снять с администратора часть работ, связанных с созданием резервных копий и восстановлением данных, и возложить их на пользователей, но для этого на компьютере клиента нужно установить дополнительное программное обеспечение. Речь идет о программе Previous Versions Client (twcli32.msi), которая находится на сервере Windows 2003 в каталоге windowssystem32clients wclientx86. Установить программу клиента можно вручную, через Group Policy или с помощью программного инструмента централизованного развертывания, например Microsoft Systems Management Server (SMS). Процесс установки не требует дополнительной настройки: чтобы удалить установленного ранее клиента, нужно просто еще раз запустить файл .msi.

После установки клиента пользователи смогут получить доступ к более ранним версиям файлов из ресурсов общего доступа. Для этого следует обратиться к соответствующему сетевому ресурсу, выбрать Properties и перейти к вкладке Previous Versions (см. Экран 3). Затем требуется выбрать одну из ранее созданных копий тома и щелкнуть View для просмотра содержимого резервной копии тома в обычном окне Windows Explorer. Теперь пользователь может выбрать и восстановить интересующие его файлы. С помощью команды Copy можно скопировать все прежнее содержимое тома целиком в другое место или же с помощью команды Restore полностью восстановить сетевой ресурс в одно из предыдущих состояний на прежнем месте.


Экран 3. Доступ к более ранним версиям файлов

Клиент Previous Versions Client назначает пользователям разрешение Modify для указанного сетевого ресурса. Таким образом, без участия администратора можно восстанавливать удаленные или устаревшие версии файлов. Очевидно, однако, что это весьма мощное средство, и для корректного использования Previous Versions Client необходимо иметь определенный навык.

VSS не избавляет от необходимости регулярно выполнять резервное копирование, он должен рассматриваться как дополнение к имеющимся средствам. VSS дает пользователям определенную независимость от администратора, но для защиты данных и системы в целом требуется тщательно продуманная стратегия резервирования. Дополнительную информацию о возможностях VSS можно найти в справочных файлах Windows 2003 Help and Support.

Кристофер Джордж — сетевой и системный инженер. Проектирует и реализует решения для бизнеса в Северной Америке и Азии. С ним можно связаться по адресу: [email protected].

www.osp.ru

Технологии виртуализации коммутаторов Cisco и Hewlett Packard Enterprise / Блог компании CBS / Хабрахабр

Сегодня хотелось бы поговорить о двух достаточно схожих технология виртуализации коммутаторов, которые позволяют объединять несколько коммутаторов в один логический. Речь пойдёт про технологии Cisco Virtual Switching System (VSS) и HPE Intelligent Resilient Framework (IRF). В рамках статьи мы рассмотрим более подробно, как работает технология VSS, после чего поговорим о технологии IRF.


Обе технологии (VSS и IRF) позволяют нам объединять коммутаторы, используя обычные Ethernet-порты. В целом данные технологии можно отнести к технологиям стекирования. Но оба вендора стараются всё же их называть технологиями виртуализации. Cisco вообще избегает слова стек в отношении VSS.

Cisco VSS

Технология VSS позволяет объединить два физических коммутатора в один логический. Но в отличии от более классических технологий стекирования (StackWise, FlexStack) для связи коммутаторов между собой используются не какие-то специализированные кабели, а Ethernet-порты. Таким образом, коммутаторы могут находиться на относительно большом удалении друг от друга.

После объединения коммутаторы начинают работать как один логический (рисунок 1). Оба коммутатора являются активными и обеспечивают передачу пакетов. При этом управление обоими коммутаторами осуществляется одним из устройств. Другими словами, уровень обработки данных (data plane) активен на обоих устройствах. А вот уровень управления (control plane) только на одном. Вспомним, что control plane (предлагаю в дальнейшем использовать именно иностранное наименование) отвечает за логику работы коммутатора: обработку всех сетевых протоколов (L2/L3), формирование таблицы маршрутизации, заполнение таблиц CEF, ACL, QoS и т.д.


Технология VSS поддерживается на следующих коммутаторах Cisco:

  • Cisco 4500E и 4500X
  • Cisco 6500E и 6800

Но взять любые два таких устройства и объединить их по технологии VSS не получится. Во-первых, не на всех супервизорах, не со всеми линейными картами, а также не со всеми сервисными модулями поддерживается технология VSS. Например, для 6500E технология VSS поддерживается на супервизорах Sup720-10GE и Sup2T. Во-вторых, технология VSS работает только между одинаковыми платформами, например, между двумя 4500X или двумя 6500E+Sup2T. Набивка устройств (линейные карты и сервисные модули) может отличаться. Также может отличаться размер шасси для коммутаторов 4500E и 6500E. Нюансов много, поэтому крайне желательно посмотреть актуальные требования к железу, версиям ПО и лицензиям на сайте вендора.

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

  • до 1,6 Тбит/с для коммутаторов серии 4500X,
  • до 1,8 Тбит/с для коммутаторов серии 4500E с супервизором Sup 8-E,
  • и до 4 Тбит/с для коммутаторов серии 6500E/6800 с супервизором Sup2T.

Архитектура VSS представлена на рисунке 2. Один из коммутаторов выбирается основным, второй коммутатор — резервным. На основном коммутаторе control plane становится активным (Active), а на резервном переходит в состояние горячего резерва (Hot Standby).
Активный control plane управляет работой обоих коммутаторов. Также в процессе работы происходит постоянная синхронизация состояния между активным control plane на основном коммутаторе и control plane на резервном коммутаторе для обеспечения отказоустойчивости. Управление и синхронизация выполняются через специальный канал – Virtual Switch Link (VSL).

Канал VSL – это прямое соединение между двумя коммутаторами (никаких промежуточных устройств не допускается). Для обеспечения VSL канала коммутаторы подключаются друг к другу через обычные Ethernet-порты. Но когда я говорю про обычные порты, я чуточку лукавлю. Как можно догадаться, к этим портам также есть определённые требования и эти требования варьируются в зависимости от платформы коммутаторов. Ко всем пакетам, которые передаются через канал VSL, добавляется специализированный заголовок – Virtual Switch Header (его длина 32 байта):

VSL может состоять из нескольких физических каналов (что собственно и рекомендуется делать). Это необходимо для отказоустойчивости нашей системы, а также получения необходимой пропускной способности. Агрегация осуществляется с помощью протоколов PAgP или LACP. Т.е. максимально мы можем иметь 8 активных каналов, объединённых в один логический VSL. Например, если мы используется порты 10 Гбит/с, мы получим до 80 Гбит/с при агрегировании 8 таких каналов.

Я думаю, многие заметили, что VSL канал является аналогом стековой шины. Поэтому очень интересно посмотреть на трафик, который предаётся через него:

  • управляющий трафик системы (трафик протоколов, обеспечивающих работу виртуального коммутатора VSS, в том числе синхронизацию состояния между коммутаторами),
  • сетевой управляющий трафик (трафик, адресованный control plane, но полученный резервным коммутатором: CDP, VTP, STP, EIGRP/OSPF и т.д.),
  • пользовательский трафик (в том числе, широковещательный и многоадресный),
  • сервисный трафик (например, SPAN).

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

  • Link Management Protocol (LMP)
  • Role Resolution Protocol (RRP)

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

Control plane на основном коммутаторе выполняет две функции. Первая – обеспечивает логику работы коммутатора: программирование коммутатора на основании конфигурации, обработку всех сетевых протоколов (L2/L3), формирование таблицы маршрутизации, таблиц CEF, управление портами и т.д. Вторая функция – заполнение всех аппаратных таблиц (FIB, Adjacency, ACL, QoS и т.д.) на обоих коммутаторах для обеспечения обработки пользовательского трафика (на аппаратном уровне). Control plane на резервном коммутаторе находится в состоянии горячего резерва. При этом состояние активного сontrol plane постоянно синхронизируется с резервным. Это необходимо для того, чтобы обеспечить беспрерывную работу нашего виртуального коммутатора в случае отказа основного физического коммутатора.

Синхронизируется следующая информация: параметры загрузки устройств, их конфигурация, состояния сетевых протоколов и различных таблиц (запущенных на активном control plane), состояние устройств (линейных карт, портов).

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

  • Serial Communication Protocol (SCP) – обеспечивает связь между процессором и линейными картами (как локальными, так и на удалённом коммутаторе)
  • Inter-process Communication Packets (IPC) – обеспечивает связь между процессорами распределённых устройств
  • Inter-Card Communication (ICC) – обеспечивает связь между линейными картами

Все эти протоколы относятся к управляющему трафику системы, который передаётся между коммутаторами по VSL каналу и образуют логический канал управления (Inter-Chassis Ethernet Out Band Channel – EOBC).

За синхронизацию состояния между коммутаторами отвечает механизм переключения с сохранением состояния (Stateful Switchover — SSO). Данный механизм появился достаточно давно. Например, он используется для резервирования супервизоров в рамках одного коммутатора 6500. Он же используется и в технологии VSS (придумывать что-то новое не стали). Но как мы помним, SSO не позволяет синхронизировать состояние протоколов маршрутизации. А значит при переключении на резервный коммутатор протоколы динамической маршрутизации запускаются с нуля. Что автоматически обрывает все L3-соединения с удалёнными устройствами. Т.е. мы получаем временную потерю связи с внешним миром. Для решения данной проблемы технология SSO работает в связке с технологией Non-Stop Forwarding (NSF). Данная технология выполняет следующие задачи: обеспечивает передачу пакетов L3 в момент переключения (по факту замораживает старые записи о всех маршрутах), оповещает удалённые маршрутизаторы о том, что не нужно рвать связь, а также запрашивает у них всю необходимую информацию для построения новой таблицы маршрутизации. Конечно, же удалённые устройства должны в этом случае также поддерживать технологию NSF (так сказать, быть NSF-aware).

Кстати, для справки: резервному коммутатору требуется до 13 секунд, чтобы полностью перезапустить процесс динамической маршрутизации. Поэтому без технологии NSF было бы совсем грустно.

А как быстро произойдёт переключение на второй коммутатор в случае отказа первого? Вендор на этот счёт приводит среднюю цифру 200 мсек. Для 6500E (видимо и для 6800 тоже) в ряде случаев она может достигать 400 мсек (так сказать, издержки распределённости архитектуры).

Что касается control plane стоит отметить ещё один момент. Так как активным control plane является только на одном из коммутаторов, весь трафик сетевых протоколов обрабатывается именно им. Например, трафик протоколов динамической маршрутизации (OSPF, EIGRP, пр.) должен в конечном итоге попасть на активный control plane. А значит, если он сначала попал на резервный коммутатор, этот трафик будет передан на основной коммутатор через VSL канал. При этом ответные пакеты могут быть отправлены напрямую с основного коммутатора (приоритетный вариант), а могут быть переданы через резервный. Это зависит от нескольких вещей: типа сетевого протокола и наличия прямого канала от основного коммутатора до получателя.

Если мы имеем дело с коммутаторами 4500E/6500E/6800, мы можем в каждый из них установить по два супервизора (так сказать, задублируем задублированное). VSS поддерживает и такую конфигурацию (называется она Quad-Supervisor). Это нужно в том случае, когда мы не хотим терять общую производительность системы, в случае выхода из строя одного из супервизоров. Для всех вариантов кроме Sup2T, второй супервизор в шасси работает в холодном резерве (Route Processor Redundancy). А это значит, что второй супервизор переходит в рабочий режим (становится резервным в разрезе VSS) только после перезагрузки всего шасси. В случае Sup2T, второй супервизор в одном шасси работает в режиме SSO и никакая перезагрузка не требуется.

Теперь давайте поговорим о передаче пользовательского трафика через виртуальный коммутатор VSS. Всё-таки это его главная задача. Одна из основных причин использовать VSS – возможность агрегации нескольких каналов, приходящих на разные коммутаторы (в терминах Cisco – Multichassis EtherChannel (MEC)). Речь идёт о подключении к виртуальному коммутатору внешних устройств (например, других коммутаторов).


Когда мы агрегируем несколько каналов в один логический в рамках VSS, может использоваться один из протоколов динамической агрегации (PAgP или LACP) или же статический EtherChannel (режим ON). За распределение трафика внутри логического канала отвечает механизм на базе хеш-функции. Хеш-функция применяется к определённым полям заголовков, передаваемого трафика. Например, хеш-функция может применяется к значению IP-адреса отправителя. В этом случае, если у нас агрегируется два канала, то по первому каналу будут передаваться потоки трафика, у которых IP-адреса отправителя чётные, а по второму — нечётные. Это позволяет распределять потоки трафика между разными каналами, объединёнными в один etherchannel. В более сложных вариантах на принятие решения о выборе канала могут влиять сразу несколько параметров (например, Src IP + Dst IP + Src Port + Dst Port).

В случае VSS всегда работает следующее правило: в первую очередь для передачи трафика внутри MEC используются локальные каналы связи (рисунок 5). Это сделано для того, чтобы не нагружать VSL канал. Замечу, что это утверждение для 6500E/6800 справедливо, как для случая MEC, так и для случая Equal Cost Multipath (если связность между виртуальным коммутатором и соседним устройством идёт по отдельным L3 каналам).


Причём не важно какая у нас общая пропускная способность каналов для каждого коммутатора. В нашем примере, даже имея двойную связь между SW2 и SW3, пакеты, поступившие на SW1 и адресованные получателям за SW3, всегда будут уходить через единственный локальный порт. Но если эта связь нарушится (или же изначально коммутатор SW3 был подключен только к SW2), весь трафик пойдёт через VSL канал (рисунок 6).
Отсюда делаем вывод, что рекомендованная схема работы VSS – это подключение устройств одновременно к обоим коммутаторам VSS (рисунок 7). В этом случае у нас трафик будет распределяться между обоими коммутаторами VSS и мы получим увеличение производительности всей системы практически в два раза по сравнению с одним коммутатором. В противном случае мы нагружаем VSL канал и теряем в суммарной производительности системы (расходуя на обработку одного потока трафика мощности обоих коммутаторов).
Для улучшения работы механизмов балансировки трафика внутри каналов MEC для технологии VSS были добавлены следующие функции:

  • Адаптивное распределение хеша – при добавлении и удалении каналов система старается сохранить потоки трафика на тех же каналах, где они были.

    В нашем примере (рисунок 8) при добавлении третьего канала, будут затронуты только 7 и 8-й потоки трафика.
  • Расширены варианты балансировки трафика между каналами (например, может использоваться номер VLAN), а также используется дополнительный псевдослучайный идентификатор Unique ID. Всё это добавлено для предотвращения эффекта поляризации трафика (когда трафик в основном передаётся только по определённым каналам, недозагружая другие).

Для того чтобы закончить с пользовательским трафиком, хотел бы отметить ещё один момент. Через канал VSL будет также передаваться трафик, который рассылается всем устройствам внутри VLAN. К такому трафику можно отнести широковещательный трафик, трафик для которого нет данных о MAC-адресе получателя (unknown unicast) и multicast-трафик.

Итак, мы выяснили что оба коммутатора обрабатывают трафик, при этом всё управление сосредоточено на одном из них. В качестве общей соединительной шины используется канал VSL, через который происходит передача как минимум управляющей и синхронизирующей информации. Через этот же канал резервный коммутатор узнаёт, что основной коммутатор «умер». Но что будет если этот канал разорвётся, при этом оба коммутатора будут исправными? Ответ прост, основной коммутатор останется активным, а вот резервный коммутатор посчитает, что его коллега отказал, и соответственно тоже станет активным (везде речь про control plane). А так как конфигурация у этих коммутаторов одна, мы получим в сети два абсолютно одинаковых устройства с идентичной адресацией. Думаю, не стоит говорить, к чему это приведёт. Для того чтобы избежать такой ситуации, как минимум не стоит разрывать VSL канал. Но не всегда это от нас зависит, поэтому есть механизм, который позволяют минимизировать последствия разрыва VSL канала. Данный механизм использует один из трёх методов обнаружения сбойной ситуации:

  • Enhanced PAgP
  • Fast Hello
  • IP BFD

После того как будет определено, что оба коммутатора стали активными в следствии обрыва канала VSL, выполняются следующие действия:

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

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

В случае работы Enhanced PAgP (прим. PAgP – проприетарный протокол) в качестве «лакмусовой бумажки» используется внешнее устройство. Каждый коммутатор VSS рассылает специальное сообщение PAgP через локальные порты в рамках одного логический канала MEC, через который подключен внешний коммутатор (рисунок 9). В таком сообщении содержится идентификатор активного коммутатора VSS. Получив ePAgP пакет, удалённое устройство его отправляет в обратную сторону. Если у нас всё хорошо, оба коммутатора отсылают один и тот же идентификатор активного коммутатора VSS. Если же оба коммутатора стали активными, каждый из них будет отсылать сообщения с собственным идентификатором (рисунок 10). А так как удалённое устройство отправляет такие сообщения обратно, оба коммутатора поймут, что наступила сбойная ситуация.


А как быстро обнаружится сбойная ситуация в этом случае? Как только коммутатор, который изначально был резервным, становится активным, он сразу же отсылает сообщение ePAgP со своим идентификатором. Таким образом, время обнаружения сбойной ситуации – доли секунд. Безусловно удалённое устройство также должно поддерживать ePAgP. Такая поддержка есть на коммутаторах 2960, 3750 (но не в стеке) и пр.

Следующий механизм — Fast Hello. В этом случае между коммутаторами VSS делается дополнительный прямой L2 канал (без промежуточных устройств). В рамках этого канала коммутаторы обмениваются сообщениями VSLP Fast Hello. И если VSL канал упал, но при этом пакеты VSLP Fast Hello продолжают ходить, у нас наступила сбойная ситуация. Время обнаружения сбойной ситуации – доли секунд (VSLP Fast Hello сообщения при падении VSL канала передаются с интервалом в 200 мсек).


Последний механизм обнаружения — IP BFD (Bidirectional Forwarding Detection). Данный механизм очень похож на работу Fast Hello, но более медленный (время обнаружения исчисляется секундами). Он может работать через прямой канал L3. Данный механизм не рекомендуется использовать из-за его медленности. Более того в последних релизах IOS он отсутствует.

Рекомендуется использовать одновременно два механизма обнаружения сбойной ситуации (обрыва VSL канала).

И так, в целом основные моменты работы технологии Cisco VSS нами рассмотрены. Остался небольшой штрих – рекомендованный дизайн использования VSS. Рассмотрим два варианта:

  • Для связи с другим оборудованием использовать несколько L3 каналов
  • Для связи с другим оборудованием использовать один L3 канал поверх агрегированного логического MEC


В первом случае отработка обрыва канала или отказа активного коммутатора VSS будет происходить средствами протокола динамической маршрутизации. При этом, так как мы будем иметь несколько равноценных маршрутов (по маршруту на каждый L3 канал), общая пропускная способность будет агрегироваться за счёт Equal Cost Multipath (ECMP). Собственно, ECMP и будет отвечать за распределение трафика по коммутаторам VSS. Во втором случае отработка обрыва канала или отказа активного коммутатора VSS будет отрабатываться аппаратно за счёт работы Multichassis EtherChannel. Благодаря средствам балансировки трафика между каналами (хеш функций) MEC будет отвечать также и за распределение трафика по коммутаторам VSS.

Сразу видны преимущества MEC по отношению к ECMP. У нас меньше логических связей с соседом (всего одна связь), меньше таблица маршрутов (от одного соседа мы принимаем всего одну копию маршрутов) и меньше нагрузка в случае отказа одного из каналов (по факту её нет, так как логический канал даже при потере одного физического будет продолжать работать). Плюс, для понимания такая конфигурация более простая.

А как же обстоят дела со временем переключения? Для unicast-трафика в обоих вариантах это время одинаковое. А вот для multicast, нет. В случае multicast-трафика время сходимости сети для ECMP существенно больше.

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

Хотел бы кратко затронуть ещё одно решение, которое использует в своей основе технологию VSS. Это решение — Cisco Catalyst Instant Access. Идея заключается в том, чтобы получить один большой виртуальный коммутатор внутри сети.

В этом случае в ядро сети (Instant Access parent) ставятся два коммутатора 6500E/6800 с супервизорами Sup2T и специализированными линейными платами, которые объединяются с помощью технологии VSS. В качестве коммутаторов уровня доступа (Instant Access client) используются коммутаторы Cisco 6800ia или 3560CX (их может быть до 42). Стоит отметить, что коммутаторы IA clients не имеют функций локальной коммутации и абсолютно все пакеты будут передаваться на коммутаторы ядра (IA parent). Правда, цена таких коммутаторов, как мне кажется, не совсем соответствует их функциональности. Но это отдельный разговор.Пример реализации технологии VSSНастроить технологию VSS достаточно просто. Начиная с версии Cisco IOS XE 3.6.0E (IOS 15.2(2)E) для объединения двух коммутаторов в один виртуальный можно использовать упрощённую схему настройки — Easy VSS. Два коммутатора соединяться друг с другом и должны быть видны на уровне L3. Далее вводится команда конвертации в VSS режим на том коммутаторе, который у нас будет основным:

SwitchA# switch convert mode easy-virtual-switch

Указываются порты, которые будут образовывать VSL канал (коммутаторы должны быть уже соединены друг с другом через эти порты):

SwitchA(easy-vss)# VSL Te1/1/15 Te1/1/16

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

Если мы настраиваем VSS классическим способом, фактически схема не сильно усложняется. На обоих коммутаторах мы настраиваем следующее:

  • Виртуальный домен (Virtual Switch Domain) и номер коммутатора в нём:

    SwitchA(config)# switch virtual domain 2

    SwitchA(config-vs-domain)# switch 1

    SwitchB(config)# switch virtual domain 2

    SwitchB(config-vs-domain)# switch 2

  • VSL Port Channel:

    SwitchA(config)# interface port-channel 1

    SwitchA(config)# switchport

    SwitchA(config-if)# switch virtual link 1

    SwitchA(config-if)# no shutdown

    SwitchB(config)# interface port-channel 2

    SwitchB(config)# switchport

    SwitchB(config-if)# switch virtual link 2

    SwitchB(config-if)# no shutdown

  • Добавляем физические порты в созданный PortChannel для VSL канала:

    SwitchA(config)# interface range tengigabitethernet 1/15-16

    SwitchA(config-if)# channel-group 1 mode on

    SwitchB(config)# interface range tengigabitethernet 1/15-16

    SwitchB(config-if)# channel-group 2 mode on

  • Запускаем конвертацию на обоих коммутаторах в режим VSS:

    SwitchA#switch convert mode virtual

    SwitchB#switch convert mode virtual

После того, как коммутаторы перейдут в режим VSS, в конфигурацию автоматически будут добавлены настройки параметров QoS для VSL канала. Дополнительно (опционально) мы можем настроить функции обнаружения ситуации с двумя активными control plane, в случае разрыва канала VSL. А также задать MAC-адрес виртуального коммутатора (по умолчанию он задаётся динамически).

Давайте теперь посмотрим, что мы получим после объединения коммутаторов на примере Cisco 4500X:


Первый коммутатор у нас стал основным/активным (VSS Active, id = 1), а второй – резервным (VSS Standby, id = 2). Control plane первого коммутатора стал активным (Control Plane State = ACTIVE), а control plane второго — резервным (Control Plane State = STANDBY), в режиме горячий резерв (Current Software state = STANDBY HOT (switchover target)). Для обеспечения отказоустойчивости у нас используется механизм SSO (Operating Redundancy Mode = Stateful Switchover). Также мы видим, что data plane на обоих коммутаторах находится в активном состоянии (Fabric State = ACTIVE).

Следующая информация показывает, какие порты у нас используются под VSL канал:


Как мы видим, порты Te1/1/15 и Te1/1/16 используются под VSL канал. Между коммутаторами запущен протокол LMP. Через оба порта по средствам протокола LMP мы видим второй коммутатор (Hello bidir).

На этом обсуждение работы Cisco VSS предлагаю завершить и перейти к решению HPE IRF.

HP Enterprise IRF

Про решение HPE IRF можно рассказать не так подробно, как про Cisco VSS. Это обусловлено тем, что информации по этой технологии не так много и чаще всего она носить достаточно поверхностный характер. Хотя может быть это и к лучшему, так не нужно «убивать» мозг в попытке разобраться с деталями. С другой же стороны не покидает чувство, что ты работаешь с неким чёрным ящиком.

В целом, если мы говорим про два коммутатора HPE, объединённые в стек (вендор допускает это определение), работа IRF и VSS очень похожа. Один из коммутаторов выбирается основным (Master), второй становится ведомым (Slave). Обработкой трафика занимаются оба коммутатора (т.е. data plane активен на обоих устройствах). Управление осуществляется основным коммутатором (на нём будет активным control plane), при этом его состояние синхронизируется с ведомым.

В качестве «стековой шины» используются обычные Ethernet-порты. На некоторых моделях для этого можно использовать даже порты 1 Гбит/с, но в большинстве случаев требуются порты минимум 10 Гбит/с. Между коммутаторами делается IRF канал (аналог VSL канала). Всем пакетам добавляет дополнительный заголовок (IRF tag).

Так как текущее состояние control plane синхронизируется между коммутаторами внутри стека, отказ основного коммутатора не приводит к остановке трафика. Такое поведение аналогично работе Cisco SSO. В отличии от Cisco VSS, синхронизация включает в том числе и состояния протоколов маршрутизации. А так как переключение занимает достаточно короткое время (вендором заявлено 50 мсек), соседние устройства не успевают обнаружить отказ одного из коммутаторов и разорвать L3-соединения. Поэтому аналог технологии Cisco NSF не требуется.

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

Что касается временных показатель, у технологии IRF они выглядят очень неплохо. Например, отмеченные выше 50 мсек являются не средним значением, а максимальным. В ряде документов указано, что по факту переключение произойдёт быстрее. Тоже самое касается времени переключения потоков трафика в случае добавления/удаления физических каналов в рамках агрегации в один логический. Приводится значение — 2 мсек. У Cisco это значение — 200 мсек. При таких временных показателях никакие адаптивные функции хеш и не требуются.

В случае, если у нас разорвётся IRF канал и оба коммутатора решат, что нужно стать активными, IRF работает по сходному алгоритму с Cisco VSS. Один из коммутаторов сохраняет свою роль основного, второй коммутатор переходит в состояние восстановления (Recovery-state). В этом состоянии он отключает все порты кроме IRF и тех портов, для которых в ручном режиме указано, что их не нужно отключать. Как только IRF канал будет восстановлен, коммутатор, который был в состояние восстановления, перезагрузится. После перезагрузки он станет ведомым (Slave).

Схемы обнаружения данного состояния (Multi-active detection) также очень похожи на те, которые мы рассмотрели в Cisco VSS. HPE IRF поддерживает следующие варианты:

  • LACP MAD (работа аналогична Cisco Enhanced PAgP)
  • BFP MAD (работа аналогична Cisco IP BFP)
  • ARP MAD (используется Gratuitous ARP, содержащий идентификатор активного устройства)
  • ND MAD (используются пакеты NS протокола Neighbor Discovery в рамках IPv6)

HPE рекомендует использовать LACP или BFP MAD, так как именно эти механизмы самые быстрые. ARP и ND MAD более медленные и требуются использования STP (что является чуточку неожиданным). Кстати сказать, механизмы используют разную логику выбора того коммутатора, который останется основным (мастером), поэтому HPE не рекомендует их использовать совместно (а именно LACP вместе с остальными).

Теперь давайте, посмотрим, чем HPE IRF отличается от Cisco VSS.

Во-первых, технология IRF поддерживается на более широком модельном ряде коммутаторов. Фактически это основная технология стекирования, которая есть и на относительно дешевых коммутаторах A3100 и на дорогих модульных 12900. В стек можно объединять коммутаторы только одного модельного ряда, правда, с небольшим исключением (совместно будут работать коммутаторы серии 5800 и 5820, а также 5900 и 5920).

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


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

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

Прежде чем завершить обзор IRF, нужно сказать о развитии данной технологии – enhanced IRF (eIRF). eIRF позволяет построить более иерархичную структуру, включающую два уровня – ядро и уровень доступа (используется архитектура Clos).


Коммутаторы, находящиеся на уровне ядра (уровень Spine для архитектуры Clos), будут выполнять функции управления (такие коммутаторы называются Controlling Bridges — CB). И фактически стек IRF запускается именно на них. Коммутаторы, находящиеся на уровне доступа (уровень Leaf для архитектуры Clos), будут выполнять лишь функции расширения портов и обеспечивать только передачу трафика (такие коммутаторы называются Port Extenders – PE). Коммутаторы PE (в ряде документов такие коммутаторы обозначаются аббревиатурой PEX) не имеют функций локальной коммутации и абсолютно все пакеты будут передаваться на коммутаторы ядра. На данный момент может быть два коммутатора ядра и до 30 коммутаторов уровня доступа. Все эти коммутаторы будут выглядеть как одно большое устройство. Ничего не напоминает? Конечно же, аналогичное решение у Cisco – это Instant Access.Пример реализации технологии IRFДавайте рассмотрим пример настройки технологии IRF.

Назначаем коммутаторам member ID. Так как по умолчанию устройства имеют member ID = 1, member ID задаём только на втором устройстве:

[Sysname2] irf member 1 renumber 2

Renumbering the member ID may result in configuration change or loss. Continue? [Y/N]:y

[Sysname2] quit

{Sysname2} reboot

Отключаем порты, которые у нас будут использоваться в IRF канале (по умолчанию они всегда выключены):

[Sysname1] interface range ten-gigabitethernet 1/0/7 to ten-gigabitethernet 1/0/8

[Sysname1-if-range] shutdown

[Sysname2] interface range ten-gigabitethernet 2/0/7 to ten-gigabitethernet 2/0/8

[Sysname2-if-range] shutdown

Закрепляем физические порты за IRF портами:

[Sysname1] irf-port 1/1

[Sysname1-irf-port2/1] port group interface ten-gigabitethernet 1/0/7

[Sysname1-irf-port2/1] port group interface ten-gigabitethernet 1/0/8

[Sysname2] irf-port 2/1

[Sysname2-irf-port2/2] port group interface ten-gigabitethernet 2/0/7

[Sysname2-irf-port2/2] port group interface ten-gigabitethernet 2/0/8

Включаем порты, которые у нас будут использоваться в IRF канале:

[Sysname1] interface range ten-gigabitethernet 1/0/7 to ten-gigabitethernet 1/0/8

[Sysname1-if-range] undo shutdown

[Sysname1-if-range] quit

[Sysname1] save

[Sysname2] interface range ten-gigabitethernet 2/0/7 to ten-gigabitethernet 2/0/8

[Sysname2-if-range] undo shutdown

[Sysname2-if-range] quit

[Sysname2] save

Активируем IRF порты:

[Sysname1] irf-port-configuration active

[Sysname2] irf-port-configuration active

После этого то устройство, которое будет ведомым, перезагрузится. Фабрика IRF собрана. Опционально настраиваем приоритет и функции MAD.

Давайте теперь посмотрим, что мы получим после объединения коммутаторов. Первый коммутатор (MemberID=1) у нас стал мастером (Master), второй коммутатор (MemberID=2) стал ведомым (Standby).

Информация по портам, которые используются для формирования IRF канала:
Информация по полученной топологии IRF:
Как мы видим, коммутаторы соединены между собой через порты IRF-Port1 на первом коммутаторе (MemberID=1) и IRF-Port2 на втором коммутаторе (MemberID=2).
Перед тем, как мы перейдём к заключительной части, хотел бы ещё раз отметить, что часть вопросов для меня остались за кадром, в особенности вопрос передачи пакетов внутри стека IRF.

Заключение

Хотел бы привести обобщающую таблицу, рассмотренных ранее технологий. Но сразу отмечу, определять «кто самый крутой в этой песочнице?» не буду. Во-первых, обе технологии являются проприетарными и по факту их использование является фактически следствием выбора того или иного вендора в качестве производителя решения для построения сетевой инфраструктуры. Во-вторых, по каждому пункту можно долго дискутировать. Например, IRF поддерживается на более широком модельном ряде. А у Cisco на младших моделях есть свои технологии стекирования. VSS поддерживает всего два коммутатора. А зачем больше? И так далее. В-третьих, я рассмотрел лишь общие функциональные моменты, оставив за кадром такие важные вопросы, как стабильность работы, удобство обслуживания, поиска проблем и пр.










Cisco VSSHPE IRF
Где поддерживается4500X, 4500E, 6500E, 68003100, 3600, 5120 и т.д.
Количество устройств, которые можно объединить29
Переключение с сохранением состоянияДа (SSO/NSF)Да
Скорость переключения в случае отказа основного коммутатора200-400 мсек50 мсек
Шина для объединения коммутаторовVSL канал, Ethernet-портыIRF канал, Ethernet-порты
Технологии обнаружения ситуации с двумя активными коммутаторамиePAgP, Fast Hello, IP BFDLACP, BFD, ARP, ND
Предотвращение проблем в сети в случае разрыва VSL/IRF каналаБлокировка портовБлокировка портов
Построение иерархичных топологийInstant AccesseIRF

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

Список литературы

Cisco VSS

Campus 3.0 Virtual Switching System Design Guide
Release 15.1SY Supervisor Engine 2T Software Configuration Guide, Virtual Switching Systems (VSS)
Release 15.1SY Supervisor Engine 720 Software Configuration Guide, Virtual Switching Systems (VSS)
Catalyst 4500 Series Switch Software Configuration Guide, IOS XE 3.8.0E and IOS 15.2(4)E, Virtual Switching Systems (VSS)

HPE IRF

HP Intelligent Resilient Fabric (IRF) — Frequently Asked Questions
HP 5920 & 5900 Switch Series IRF Configuration Guide
HP FlexFabric 12900 Switch Series IRF Configuration Guide
h4C IRF Technology White Paper

habr.com

Что такое и зачем Oracle VSS Writer Service?

Volume Shadow Copy Service (VSS) — это инфраструктуры на платформе Windows Server, которая позволяет приложениям создавать теневые копии (shadow copies). Теневая копия — это согласованный! снимок данных на четко определенный момент времени.

Короче говоря эта инфраструктура позволяет делать согласованные! снимки отдельных файлов или всего тома (диска) без остановки работы. И это обеспечивается ядром ОС Windows.

Сервис Oracle <SID> VSS Writer Service — это сервис Oracle, который обеспечивает координацию между отдельным экземпляром Oracle (на каждый экземпляр создается свой сервис) и VSS инфраструктурой.

Это позволяет, используя ПО сторонних производителей, выполнять «горячее» резервное копирование и восстановление. Например, можно использовать программные продукты Acronis (1567: Creating Backup with Complex Applications Such As Microsoft SQL Server, Oracle or Microsoft Exchange Running on the Server).

Подробнее всё это описано в документации — 8 Performing Database Backup and Recovery with VSS.

——————————————————————————————-

Если резервирование выполняется без использования VSS, лучше отключить или вообще удалить эти службы Oracle <SID> VSS Writer Service. Т.к. они потребляют ресурсы. А так же возможна утечка памяти (unpublished Bug:9063341) — Instance Crash Or ORA-04030 Errors When Pagefile Is Full [ID 1358570.1] или Bug 10209909 : ORAVSSW PROCESS CONSUME ALL MEMORY

Для управления службой можно использовать oravssw — Installing and Uninstalling the Oracle VSS Writer Service

Удалить сервис:

oravssw <SID> /d

 

ENG: http://ministrbob.wordpress.com/2012/07/24/what-is-and-what-for-oracle-vss-writer-service

Запись опубликована в рубрике !RUS, Admin, Concepts, ORACLE. Добавьте в закладки постоянную ссылку.

dmitrybobrovsky.ru

Файл с расширением VSS | Чем и как открыть файл .VSS

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

  • Что такое файл .vss?
  • Какое программное обеспечение мне нужно открыть файл .vss?
  • Как файл .vss быть открыты, отредактированы или напечатано?
  • Как конвертировать .vss файлов в другой формат?
  • Где могу найти спецификации для .vss?
  • MIME-тип связан с расширением .vss?

Мы надеемся, что вы найдете на этой странице полезный и ценный ресурс!

1 расширений и 0 псевдонимы, найденных в базе данных

Microsoft Visio Stencil

.vss

Описание (на английском языке):
VSS file is a Microsoft Visio Stencil. Microsoft Visio is diagramming software for Microsoft Windows. It uses vector graphics to create diagrams. A stencil (VSS) is a collection of shapes associated with a particular Microsoft Office Visio template (VST).

MIME-тип: application/vnd.visio

Магическое число: —

Магическое число: —

Образец: —

VSS псевдонимы:

VSS cсылки по теме:

VSS связанные расширения:

Microsoft Visio Diagram

Microsoft Visio Workspace

Microsoft Visio Template

Microsoft Visio Stencil XML

Microsoft Visio Diagram XML

Microsoft Visio Template XML

Microsoft Visio Library

Microsoft Visio Report Definition

Microsoft Visio 2013 Drawing

Microsoft Visio 2013 macro-enabled Drawing

Другие типы файлов могут также использовать расширение файла .vss.

Расширение файла .vss часто дается неправильно!

По данным Поиск на нашем сайте эти опечатки были наиболее распространенными в прошлом году:

vws,
bss,
vsx,
vsq,
vsc,
vqs,
vcs,
ss,
fss,
vxs,
css,
vsz,
vsw,
vse,
vs

Это возможно, что расширение имени файла указано неправильно?

Мы нашли следующие аналогичные расширений файлов в нашей базе данных:

Resident Evil Background Image

Microsoft Visio Stencil XML

GameBoy Advance Saved State

Mcafee VirusScan Settings

Digital Speech Standard Voice

VeriWave WaveTest Sequence Data

Не удается открыть файл .vss?

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

Windows не удается открыть этот файл:

пример.vss

Чтобы открыть этот файл, Windows необходимо знать, какую программу вы хотите использовать для его открытия…

Если вы не знаете как настроить сопоставления файлов .vss, проверьте FAQ.

Можно ли изменить расширение файлов?

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

Если у вас есть полезная информация о расширение файла .vss, напишите нам!

www.filesuffix.com

Как открыть VSS файлы — Файлы с расширением VSS

Что обозначает расширение VSS?

автор: Jay Geater, главный писатель по вопросам технологий

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

До того, как вы сможете открыть файл VSS, вам необходимо выяснить, к какому виду файла относится расширения файла VSS.

Tip: Incorrect VSS file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.

Ответ:

Файлы VSS имеют Файлы растровых изображений, который преимущественно ассоциирован с Shapeware Visio Smartshapes File.

Файлы VSS также ассоциированы с
Visio Stencil (Microsoft Corporation) и FileViewPro.

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


Как открыть ваш файл VSS:

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

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

Если ваш ПК открывает файл VSS, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов VSS с неверной программой.

We highly recommend scanning your Windows registry for invalid file associations and other related registry issues.

Загрузки программного обеспечения, связанные с расширением файла VSS:

* Некоторые форматы расширений файлов VSS можно открыть только в двоичном формате.

Скачать FileViewPro для открытия ваших файлов VSS прямо сейчас

Установить необязательные продукты — FileViewPro (Solvusoft) | Лицензия | Политика защиты личных сведений | Условия | Удаление


VSS Multipurpose Internet Mail Extensions (MIME):


VSS Инструмент анализа файлов™

Вы не уверены, какой тип у файла VSS? Хотите получить точную информацию о файле, его создателе и как его можно открыть?

Теперь можно мгновенно получить всю необходимую информацию о файле VSS!

Революционный VSS Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле VSS. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†

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

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

Ваш файл анализируется… пожалуйста подождите.

Имя файла:

Размер файла:

Прервать

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


Установить необязательные продукты — FileViewPro (Solvusoft) | Лицензия | Политика защиты личных сведений | Условия | Удаление

Об авторе: Джей Гитер (Jay Geater) является президентом и генеральным директором корпорации Solvusoft — глобальной компании, занимающейся программным обеспечением и уделяющей основное внимание новаторским сервисным программам. Он всю жизнь страстно увлекался компьютерами и любит все, связанное с компьютерами, программным обеспечением и новыми технологиями.

www.solvusoft.com