Когда мне потребовалось выполнить обновление прошивки Fabric OS (FOS) на стареньких FC коммутаторах Brocade SilkWorm 4100 до актуальной версии, оказалось что без действующего сервисного контракта с сайта Brocade не представляется возможным скачать файлы необходимые для обновления. Однако в поисках решения я наткнулся на довольно информативную статью об особенностях обновления FOS, из которой понял, что найти файлы, необходимые для обновления можно и в открытых источниках, например на сайтах таких вендоров как HP или IBM. В другой статье этого же блога я нашёл подтверждение того, что прошивки FOS для коммутаторов Brocade выпущенных "под соусом" разных вендоров могут быть вполне идентичными, а мои последующие эксперименты с обновлением коммутаторов Brocade выпущенных под маркой EMC это ещё раз доказали.
В этой заметке мы рассмотрим пример восстановления учётных записей по умолчанию для FC коммутатора Brocade SilkWorm 4100. В моём примере будет использоваться коммутатор с прошивкой Fabric OS (FOS) 5 версии. В качестве основного руководства к действию можно использовать документ Fabric OS Password Recovery Notes (53-1000114-05 от 13.02.2012) в котором описаны процедуры восстановления FOS версий 2.6 - 6.x. На данный момент документ можно скачать с сайта Brocade по 
C помощью описанной 
Несмотря на довольно стабильную работу прокси-сервера Squid в средах с большим количеством пользователей, может возникнуть желание повышения уровня доступности такого важного на сегодняшний день информационного ресурса, как доступ в Интернет для конечных пользователей. В этой заметке будет рассмотрен пример настройки двух прокси-серверов Squid для повышения доступности с параллельным распределением нагрузки между этими серверами.
При начале эксплуатации 
В этой заметке будет рассмотрена процедура обновления Squid 3.3.8 до последней стабильной версии 3.5.3, которая будет несколько отличаться от описанной 
На завершающей стадии виртуализации имеющихся серверных ресурсов дело дошло до, казалось бы, самого “неподъёмного” сервера – сервера System Center 2012 R2 DPM. Таковым сервер изначально казался по той причине, что имел прямое подключение к внешним дисковым полкам через выделенный SAS контроллер. В моём случае используются дисковые полки HP D2600 на 12 LFF дисков каждая, подключаемые к физическому серверу DPM через SAS-контроллер HP SmartArray P800. Фактически вопрос переброса самих дисковых полок в виртуальную среду был решён с помощью их подключения к СХД HP P2000 G3 с последующей трансляцией дисковой ёмкости с помощью технологии NPIV внутрь виртуальной машины с DPM. Однако перед тем как отключить дисковую полку от действующего физического DPM, возник вопрос о том, как же сохранить имеющиеся резервные копии данных на этой полке (чтобы не терять возможность восстановления из бэкапов созданных до момента переезда на новый виртуальный DPM). Выяснилось, что у DPM есть штатный механизм копирования разделов с одного физического диска входящего в DPM Storage Pool на другой. Рассмотрим кратко эту процедуру на нашем примере.
Добавляем дополнительный хост виртуализации в действующий кластер Hyper-V на базе Windows Server 2012 R2 с использованием общих томов Cluster Shared Volume (CSV). Устанавливаем на новый узел кластера агента System Center 2012 R2 DPM CU5 и пытаемся выполнить резервное копирование виртуальных машин из кластера. При этом возникает интересная проблема – резервное копирование виртуальных машин успешно выполняется только в том случае, если они расположены на уже существующих ранее в DPM узлах кластера, а если переместить любую виртуальную машину на новый узел кластера, то в процессе создания резервной копии сначала возникает ошибка…
Здравствуйте, Кирилл. В рассматриваемом примере 8 и 9 это не разные сети, а одна расширенная сеть. Обратите внимание на то,…
RSS - Записи
Последние комментарии