Дисковые библиотеки Data Domain с технологией дедупликации

Компания EMC недавно купила изготовителя дисковых библиотек Data Domain и начала продвигать ее продукцию в России. Вся линейка дисковых библиотек с дедупликацией Data Domain включает в себя сейчас 8 продуктов.

Флагманским продуктом в консолидированных библиотеках Data Domain является модель DD880. Само устройство представляет из себя единый контроллер высотой 4RU, к которому подключены дисковые полки c 0.5 или 1 ТБ SATA дисками в RAID-6. Полезная (сырая) емкость – 5,4-71 ТБ. Логический объем хранимых данных – 1,4 – 3,5 ПБ. Внешние интерфейсы – 1-10 Гбит/с NIC и 4 Гбит/с FC. Для модели DВ880 скорость резервного копирования составляет 5,4 ТБ/час по протоколу OpenStorage и 2,5 ТБ/ч по протоколу tape library emulation (VTL) over Fibre Channel. Скорость восстановления данных меньше на 20%.

Устройство работает на модифицированной и доработанной ОС Red Hat Linux.

Перестроение RAID групп длится около 1 часа для дисков объемом 500 ГБ и не влияет на скорость резервного копирования.

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

Использование библиотек с дедупликацией позволяет сократить объем данных даже после инкрементального копирования на 80%.
Удаление устаревших данных (garbage collection) происходит в фоновом режиме и не требует окна в резервном копировании.

Заявляется в среднем сокращение объема данных при дедупликации:
• Первая копия – х2
• Инкрементальное копирование - x10
• Полная копия – x20

Есть раздел Data Domain Resource Center на powerlink.emc.com - https://powerlink.emc.com/nsepn/webapps/btg548664833igtcuup4826/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=image7b&internalId=0b014066804651a4&_irrt=true

Проверка действительности сертификата SSL в броузере Internet Explorer

При обсуждении деталей создания единого удостоверяющего центра для организации заказчика возник вопрос о проверке цифровых сертификатов типа X.509, используемых для организации сессии SSL протокола HTTPS при публикации web-приложений в Интернет. Вопрос довольно простой - проверяет ли броузер действительность сертификата не только по дате издания и названию ресурса, но и по опубликованному списку отозванных сертификатов? Ответ нашелся не быстро (помогли коллеги из ssl.ru) поэтому публикую его отдельной статьей.

Вопрос.

Осуществляет ли броузер Internet Explorer или Firefox проверку корректности cертификата SSL перед началом сессии HTTPS согласно списку отозванных сертификатов провайдера этого сертификата? Или же проверяется только корректность подписи удостоверяющего центра этого сертификата, даты его действия и соответствия имени ресурса указанному в сертификате? Если осуществляется проверка по CRL то как часто он
обновляется? Или действует иная схема аутентификации ресурса и сертификата?

Ответ.

С версий Internet Explorer 7.0 или Firefox 5.0 осуществляются автоматически проверка корректности сертификатов (по CRL файлу сертификационного центра), в том случае если удалось соединиться с корневым центром сертификации. Но каждый конкретный пользователь или администратор может запретить эту проверку, по-умолчанию.

Проверка аннулированных сертификатов в Internet Explorer активируется в свойствах обозревателя: Internet Options -> Advanced -> "Check for publishers certificate revocation"/ Свойства обозревателя -> Дополнительно -> "Проверять аннулирование сертификатов издателя".

При этом, конечный пользователь, который будет заходить на сайт, защищенный сертификатом, в любой момент сможет самостоятельно проверить является ли тот сертификат, который он просматривает, действительным. Для этих целей, например, в Thawte предусмотрено расположение баннера, нажав на который Вы переходите на страницу проверки валидности сертификата. Так же предусмотрена страница, где можно по доменному имени проверить сертификат, даже если баннер отсутствует:
https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO9555&actp=RELATED_RESOURCE

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

Нотация моделирования бизнес-процессов (Business Process Modeling Notation, BPMN)

BPMN - это графическая нотация для моделирования бизнес-процессов. BPMN была разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group. Привожу выдержки из статьи в Wikipedia и сайта bpmn.org.


Элементы

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

BPMN 1.2 Постер постер на русском языке, показывающий использование конструкций BPMN 1.2.

• Объекты потока управления: события, действия и логические операторы
• Соединяющие объекты: поток управления, поток сообщений и ассоциации
• Роли: пулы и дорожки
• Артефакты: данные, группы и текстовые аннотации.
  

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

Объекты потока управления

Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и логические операторы (gateways).

События

изображаются окружностью и означают какое-либо происшествие в мире. События инициируют действия или являются их результатами. Согласно расположению в процессе события могут быть классифицированы на начальные (start), промежуточные (intermediate) и завершающие (end). Начиная с BPMN 1.1 различают события обработки и генерации. Ниже представлена категоризация событий по типам.

* Простые события (plain events) это нетипизированные события, использующиеся, чаще всего, для того, чтобы показать начало или окончание процесса.
* События-сообщения (message events) показывают получение и отправку сообщений в ходе выполнения процесса.
* События-таймеры (timer events) моделируют события, регулярно происходящие во времени. Также позволяют моделировать моменты времени, периоды и таймауты.
* События-ошибки (error events) позволяют смоделировать генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.
* События-отмены (cancel events) инициируют или реагируют на отмену транзакции.
* События-компенсации (compensation events) инициируют компенсацию или выполняют действия по компенсации.
* События-условия (conditional events) позволяют интегрировать бизнес правила в процесс.
* События-сигналы (signal events) рассылают и принимают сигналы между несколькими процессами. Один сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.
* Составные события (multiple events) моделирует генерацию и моделирование одного события из множества.
* События-ссылки (link events) используются как межстраничные соединения. Пара соответствующих ссылок эквивалентна потоку управления.
* События-остановы (terminate events) приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).

Действия

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

* Задание (task) это единица работы, элементарное действие в процессе.
* Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.
* Циклическое действие (loop activity) выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.
* Свёрнутый подпроцесс (collapsed subprocess) является сложным действием и содержит внутри себя правильную ДБП.
* Развёрнутый подпроцесс (expanded subprocess) также является составным действием, но скрывает детали реализации процесса.
* Ad-hoc подпроцесс (ad-hoc subprocess) содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.

Логические операторы

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

* Оператор исключающего ИЛИ управляемый данными (data-based exclusive gateway) Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.
* Оператор исключающего ИЛИ управляемый событиями (event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.
* Оператор И (parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.
* Оператор включающего ИЛИ (inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор синхронизирует потоки, то он ожидает завершения выполнения всех активированных ветвей и затем активирует выходной поток.
* Сложный оператор (complex gateway) имеет несколько условий, в зависимости от выполнения которых активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не выражены на диаграмме. Вследствие этого использование оператора нежелательно.


Соединяющие объекты

Объекты потока управления связаны друг с другом соединяющими объектами. Существует три вида соединяющих объектов: потоки управления, потоки сообщений и ассоциации.
Типы потоков управления в BPMN 1.1

Поток управления

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



Поток сообщений

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



Ассоциации

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


Роли

Роли — визуальный механизм организации различных действий в категории со сходной функциональностью. Существует два типа ролей:
Типы ролей в BPMN 1.1

Пулы

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


Артефакты

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

Данные

показывают читателю какие данные необходимы действиям для выполнения и какие данные действия производят.

Группа

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

Текстовые аннотации

используются для уточнения значения элементов диаграммы и повышения её информативности.



Источники - http://ru.wikipedia.org/wiki/BPMN

Показатели быстродействия дисковой подсистемы массивов CLARiiON

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

Восстановление RAID c наивысшей скоростью (ASAP) для типов RAID c контролем четности и зеркалированием и дисков Fibre Channel без внешней нагрузки:

• Mirrored RAID - 70 MB/s
• Parity RAID-5 - 50 MB/s
  

Ограниченные скорости восстановления RAID c c контролем четности и зеркалированием и дисками Fibre Channel:

• Low - 2 MB/s
• Medium - 6 MB/s
• High - 13 MB/s

Влияние размера группы RAID c контролем четности на восстановление:

• группа из 6 дисков: RAID-5 50 MB/s, RAID-6 50 MB/s;
• группа из <= 9 дисков: RAID-5 34.1 MB/s, RAID-6 27.3 MB/s;
• группа из <= 12 дисков: RAID-5 24.4 MB/s, RAID-6 22.2 MB/s;
• группа из >=15 дисков: RAID-5 17.9 MB/s, RAID-6 17.4 MB/s.

Количество операций ввода\вывода для операция с маленькими блоками для различных дисков:

• Fibre Channel 15k rpm 180 IOPS,
• SAS 15k rpm 180 IOPS,
• Fibre Channel 10k rpm 140 IOPS,
• SATA 7.2k rpm 80 IOPS,
• SATA 5.4k rpm 40 IOPS,
• EFD 2500 IOPS.

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

• Fibre Channel 15k rpm: блоки 64 KB - 8.0 MB/s, блоки 512 KB - 32.0 MB/s,
• SAS 15k rpm: блоки 64 KB - 6.0 MB/s, блоки 512 KB - 32.0 MB/s,
• Fibre Channel 10k rpm: блоки 64 KB - 8.0 MB/s, блоки 512 KB - 24.0 MB/s,
• SATA 7.2k rpm: блоки 64 KB - 4.0 MB/s, блоки 512 KB - 16.0 MB/s,
• SATA 5.4k rpm: блоки 64 KB - 2.5 MB/s, блоки 512 KB - 12.0 MB/s,
• EFD: блоки 64 KB - 100 MB/s, блоки 512 KB - 100 MB/s.

Определение количество операций ввода\вывода на дисковую подсистему для разных типов RAID:

• Parity RAID 5 and 3: Disk IOPS = Read IOPS + 4*Write IOPS,
• Parity RAID 6: Disk IOPS = Read IOPS + 6*Write IOPS,
• Mirrored RAID: Disk IOPS = Read IOPS + 2*Write IOPS.
  

Источник - "EMC CLARiiON Performance and Availability: Release 28.5 Firmware Update Applied Best Practices".

Асиметричная маршрутизация с межсетевыми экранами Cisco (ASA, FWSM)

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

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

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

Асимметричная маршрутизация возвращающегося трафика активируется команды asr-group group_id, выполненной в режиме конфигурации интерфейса.

Context ctx1 configuration:
hostname/ctx1(config)# interface Vlan101
hostname/ctx1(config-if)# nameif outside
hostname/ctx1(config-if)# ip address 192.168.1.11 255.255.255.0 standby 192.168.1.21
hostname/ctx1(config-if)# asr-group 1

Context ctx2 configuration:
hostname/ctx2(config)# interface Vlan102
hostname/ctx2(config-if)# nameif outside
hostname/ctx2(config-if)# ip address 192.168.1.31 255.255.255.0 standby 192.168.1.41
hostname/ctx2(config-if)# asr-group 1

Модуль FWSM поддерживает до 32 групп асимметричной маршрутизации (групп ASR). Каждая группа ASR поддреживает до 8 интерфейсов. Режим асимметричной маршрутизации поддерживается с использованием групп ASR в режиме отказоустойчивого кластера "активный/активный" и в обычном режиме без отказоустойчивости, либо в одиночном режиме, либо внутри виртуального межсетевого экрана. Асимметричная маршрутизация поддерживается как в прозрачном, так и в маршрутизирующем режимах работы межсетевых экранов.

Асимметричная маршрутизация с группой ASR с одним устройством FWSM.


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

Когда интерфейс, сконфигурированный с использованием команды asr-group, получает пакет, для которого нет сессионной информации, он проверяет информацию о сессиях для других интерфейсов из его группы. Если совпадение не найдено, пакет отбрасывается. Если совпадение находится и входящий трафик исходил из другого интерфейса той же группы, часть заголовка 2 уровня пакета переписывается и пакет передается целевому хосту.

После того, как пакет синхронизации (SYN) отправлен из группы ASR, устройство FWSM будет принимать возвращающийся пракет подтверждения синхронизации (SYN ACK) на любом интерфейсе из группы ASR.

Асимметричная маршрутизация в топологии отказоустойчивого кластера "активный/активный".

Интерфейсы внутри обычной группы ASR в топологии кластера "активный/активный" также поддерживают асимметричную маршрутизацию.

В топологии "активный/активный", когда интерфейс, сконфигурированный командой asr-group, получает пакет, для которого нет сессионной информации, он проверяет сессионную информацию для других интерфейсов, находящихся в той же группе. Если совпадение не найдено, пакет отбрасывается. Если совпадение находится и входящий трафик исходил из соседнего устройства, которое было активным для контекста, часть или целый заголовок 2 уровня пакета переписывается и пакет перенаправляется активному устройству.


На рисунке показано, что трафик передается через исходящий интерфейс на контексте А устройства, где контекст А находится в неактивном состоянии и возвращается через внешний интерфейс контекста А на устройстве, где контекст А находится в активном состоянии. Это перенаправление продолжается, пока сессия остается активной.

Источник - Authorized Self-Study Guide: Designing Cisco Network Service Architectures (ARCH)