SAN

SAN, или Storage Area Network, — специализированная сеть хранения данных, которая соединяет серверы с централизованными системами хранения и предоставляет им доступ к дисковым ресурсам на блочном уровне.

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

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

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

Что такое SAN простыми словами

Представим несколько серверов, которым требуется надежное и быстрое хранилище.

Вместо установки большого количества дисков в каждый Server можно подключить их к общей Storage System:

Server 1 ─┐
Server 2 ─┼→ SAN network → Storage array
Server 3 ─┘

Система хранения создает логические диски и предоставляет их нужным серверам.

Расшифровка SAN

SAN расшифровывается как Storage Area Network — сеть хранения данных.

Это отдельная инфраструктура, предназначенная в первую очередь для передачи Storage Traffic между Servers и системами хранения.

Для чего нужен SAN

SAN используют, когда организации требуется:

• централизованное высокопроизводительное хранилище;
• общий Storage для нескольких серверов;
• виртуализация;
• кластеризация;
• высокая доступность;
• быстрое масштабирование емкости;
• централизованное управление дисковыми ресурсами.

Block Storage

Главная особенность SAN — Block-level Access.

Storage System предоставляет серверу набор блоков:

Storage array
↓
Logical block device
↓
Server
↓
File system

Server сам решает, какую File System создать на этом устройстве.

SAN и NAS

SAN и NAS часто путают, потому что оба решения хранят данные централизованно.

Пример SAN и NAS

NAS предоставляет:

storageinance

SAN предоставляет серверу условный диск:

Disk 2: 5 TB

После этого Server форматирует его и создает собственную File System.

Основные компоненты SAN

Типичная архитектура включает:

• Servers;
• Host Bus Adapters;
• SAN Switches;
• Storage Array;
• Storage Controllers;
• Disks или SSD;
• Management Software.

Storage Array

Storage Array — система хранения, содержащая накопители, Controllers, Cache и интерфейсы подключения к SAN.

Она объединяет физические диски и предоставляет Servers логические Storage Resources.

Storage Controller

Controller управляет операциями чтения и записи, RAID или другими механизмами защиты данных, Cache и взаимодействием с Host.

Корпоративные массивы часто имеют несколько Controllers для отказоустойчивости.

Dual Controller

Два Storage Controllers позволяют продолжить работу при отказе одного из них в поддерживаемой архитектуре.

Server
↓
Controller A / Controller B
↓
Storage pool

Для настоящей отказоустойчивости необходимо также иметь независимые Network Paths.

Host Bus Adapter

HBA, или Host Bus Adapter, — интерфейс Server для подключения к SAN.

Особенно этот термин распространен в Fibre Channel Infrastructure.

SAN Switch

SAN Switch соединяет Servers и Storage Ports внутри Storage Network.

Он выполняет похожую по общей идее роль на Ethernet Switch, но может работать с технологиями, специально предназначенными для Storage Traffic.

Fibre Channel

Fibre Channel, или FC, — одна из классических технологий построения SAN.

Она предназначена для передачи Storage Traffic с низкой задержкой и высокой надежностью.

Fibre Channel не означает обычный Ethernet по оптике

Несмотря на название, Fibre Channel является отдельной технологией и протоколом, а не просто Ethernet Connection через оптический кабель.

Fibre Channel Fabric

Совокупность FC Switches, Links, Servers и Storage Interfaces называют Fabric.

Server HBA
↓
FC switch fabric
↓
Storage port

WWN

World Wide Name, или WWN, — уникальный идентификатор Fibre Channel Device или Port.

Он используется для адресации, Zoning и управления доступом.

WWPN

World Wide Port Name идентифицирует конкретный FC Port.

Администратор может использовать WWPN сервера при настройке Zoning и доступа к LUN.

iSCSI

iSCSI позволяет передавать SCSI Commands через IP Network.

Это дает возможность строить SAN на базе стандартного Ethernet.

Server
↓ Ethernet / IP

iSCSI
↓
Storage

Преимущества iSCSI

• использует привычную Ethernet Infrastructure;
• не требует отдельной FC Fabric;
• подходит для малого и среднего дата-центра;
• может работать через стандартные Network Adapters.

Ограничения iSCSI

Storage Traffic конкурирует за Network Resources, если инфраструктура плохо спроектирована.

Поэтому iSCSI часто выделяют в отдельные VLAN, Interfaces или физическую Network Fabric.

iSCSI Initiator

Initiator — клиентская сторона iSCSI, обычно Server.

Он подключается к Storage Target и получает доступ к блочному устройству.

iSCSI Target

Target — сторона, предоставляющая Storage Resource.

Initiator → iSCSI Target → LUN

Target может находиться на специализированной Storage System или программном сервере хранения.

FCoE

Fibre Channel over Ethernet позволяет передавать Fibre Channel Frames через Ethernet Infrastructure в соответствующей архитектуре.

Он используется в отдельных корпоративных средах для конвергенции сетей.

NVMe over Fabrics

Современные Storage Systems могут использовать NVMe over Fabrics для удаленного доступа к NVMe Storage с низкой задержкой.

Этот подход предназначен для высокопроизводительных Workloads.

LUN

LUN, или Logical Unit Number, — логический Storage Resource, который система хранения предоставляет Server.

Например, Storage Admin создает LUN размером 2 TB и назначает его Database Server.

Storage pool
↓
LUN 2 TB
↓
Database server

LUN и физический диск

LUN не обязательно соответствует одному физическому HDD или SSD.

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

Storage Pool

Storage Pool объединяет физические ресурсы системы хранения.

Из него создаются логические Volumes и LUN нужного размера.

LUN Masking

LUN Masking определяет, каким Servers разрешено видеть конкретный LUN.

Server A не должен автоматически получать доступ к дискам Server B.

Zoning

В Fibre Channel SAN Zoning ограничивает взаимодействие между Ports или WWN.

Например:

DB server HBA → DB storage ports : allow
Web server HBA → DB storage ports : deny

Это уменьшает нежелательную связность внутри Fabric.

Zoning и LUN Masking

Эти механизмы дополняют друг друга.

Zoning ограничивает Network-level видимость, а LUN Masking определяет, какие Storage Resources доступны конкретному Host.

Multipathing

Multipathing позволяет Server использовать несколько независимых путей до Storage.

Server
├→ Switch A → Controller A
└→ Switch B → Controller B

Если один Link, Switch или Controller перестает работать, I/O может продолжиться по другому пути.

MPIO

Multipath I/O, или MPIO, управляет несколькими путями до одного Storage Device.

В зависимости от Policy он может использовать пути для Failover или распределять между ними нагрузку.

Почему SAN без Multipathing менее надежна

Даже дорогой Storage Array не обеспечивает высокой доступности, если Server подключен к нему одним Cable через один Switch.

Такой Link становится Single Point of Failure.

Две SAN Fabric

В критичной FC Infrastructure часто используют две независимые Fabric:

Fabric A
Server ───────── Storage

Fabric B
Server ───────── Storage

Отказ одной Fabric не должен останавливать Storage Access.

High Availability SAN

Высокая доступность достигается комбинацией:

• двух Controllers;
• нескольких HBA;
• двух Switch Fabrics;
• Multipathing;
• RAID или других механизмов избыточности;
• резервного питания.

SAN и RAID

Внутри Storage Array физические накопители часто объединяются в RAID или иной механизм защиты.

SAN отвечает за предоставление Storage через сеть, а RAID — за избыточность дисков.

SAN не является RAID

Можно иметь RAID внутри локального сервера без SAN.

И наоборот, SAN Array почти всегда имеет собственный механизм защиты накопителей, но эти понятия находятся на разных уровнях.

SSD в SAN

Современные системы хранения часто используют SSD для высокопроизводительных Workloads.

All-flash Storage Array полностью строится на Flash Storage и обеспечивает значительно более низкую Latency по сравнению с классическими HDD-массивами.

HDD в SAN

HDD по-прежнему подходят для емких Storage Tiers, архивов и Workloads, где стоимость одного терабайта важнее минимальной задержки.

Hybrid Storage Array

Hybrid Array объединяет HDD и SSD.

Часто используемые данные могут размещаться на более быстром Storage Tier, а редко используемые — на емком.

Storage Tiering

Tiering распределяет данные между разными классами накопителей.

Hot data → fast SSD
Warm data → standard storage
Cold data → capacity tier

Это помогает балансировать стоимость и производительность.

Cache в SAN

Storage Controllers используют RAM или Flash Cache для ускорения операций.

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

Read Cache

Часто читаемые Blocks могут обслуживаться из Cache без обращения к физическим накопителям.

Write Cache

Write-back Cache позволяет быстро подтвердить операцию записи, а физическую запись выполнить позже.

Для критичных систем Cache должна быть защищена от отказа питания и Controller Failure.

SAN и IOPS

IOPS — количество операций ввода-вывода в секунду.

Для Virtualization и Database это одна из ключевых характеристик Storage.

SAN и Latency

Высокое количество IOPS бесполезно, если каждая операция выполняется с большой задержкой.

Database Workloads особенно чувствительны к Storage Latency.

Throughput

Throughput показывает объем данных, передаваемых за единицу времени.

Большие последовательные Backup Jobs требуют высокой пропускной способности, тогда как OLTP Database чаще чувствительна к Latency и Random IOPS.

Queue Depth

Queue Depth показывает количество I/O Requests, ожидающих обработки.

Слишком большая очередь может указывать на Storage Bottleneck.

Storage Bottleneck

Если SAN не справляется с нагрузкой, могут расти:

• Latency;
• Application Response Time;
• Database Waits;
• VM Stun или задержки;
• Backup Duration.

SAN и виртуализация

SAN широко используется как общий Storage для Hypervisor Cluster.

Hypervisor 1 ─┐
Hypervisor 2 ─┼→ SAN → shared datastore
Hypervisor 3 ─┘

Несколько Hosts получают доступ к одному Storage, что позволяет переносить Virtual Machines между Nodes.

SAN и Live Migration

Если VM Disks находятся на общем Storage, Hypervisor может переместить выполнение VM между Hosts без копирования всего виртуального диска.

Это упрощает обслуживание и High Availability.

SAN и Hyper-V

В Hyper-V блочное Storage может использоваться для Cluster Shared Volumes и других сценариев виртуализации.

Для отказоустойчивого Cluster особенно важны MPIO и отсутствие Single Point of Failure.

SAN и VMware

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

Конкретные Storage Protocols и возможности зависят от архитектуры Hypervisor и массива.

SAN и Proxmox

Proxmox может использовать iSCSI и другие Shared Storage варианты в зависимости от выбранной конфигурации.

При блочном общем Storage особенно важно правильно выбрать механизм File System или Volume Management.

SAN и Database

SAN хорошо подходит для крупных Database Systems благодаря централизованному управлению производительностью и отказоустойчивостью.

Database Server получает LUN и использует его как обычное блочное устройство.

SAN и SQL Server

При размещении Database на SAN необходимо учитывать:

• Latency;
• IOPS;
• Write Cache;
• Multipathing;
• Storage Queue;
• разделение разных типов нагрузки.

Высокая производительность самого Server не компенсирует медленную Storage System.

SAN и Oracle Database

Крупные корпоративные Database Workloads также могут использовать SAN для централизованного Storage и Cluster Architectures.

Storage Design должен соответствовать требованиям конкретной СУБД и профилю нагрузки.

SAN и 1С

В клиент-серверной инфраструктуре 1С SAN может использоваться для хранения Virtual Machines и Database Files, особенно в крупных виртуализированных средах.

Для производительности 1С важны не название Storage Technology, а реальные показатели Latency, IOPS и стабильность работы под нагрузкой.

SAN для SQL-базы 1С

Если Database Server размещен на SAN, следует отдельно оценивать нагрузку на Data Files, Transaction Logs, Temp Data и Backup.

Слишком перегруженный общий Storage способен замедлить сразу несколько бизнес-систем.

Noisy Neighbor

Несколько Applications могут использовать один Storage Pool.

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

Это называют эффектом Noisy Neighbor.

QoS в SAN

Storage Quality of Service может ограничивать или гарантировать IOPS и Throughput для отдельных Volumes или Hosts.

Это помогает разделять критичные и некритичные Workloads.

SAN и кластер

Shared Storage является важным компонентом многих Failover Clusters.

Несколько Servers могут иметь доступ к одному набору данных, но координация записи должна выполняться Cluster Software или специальной File System.

Почему нельзя просто подключить один LUN к двум обычным серверам

Если два независимых Server одновременно монтируют обычную File System и записывают в нее без кластерной координации, данные могут быть повреждены.

Для Shared Block Storage требуется архитектура, понимающая одновременный доступ нескольких Hosts.

Cluster File System

Cluster-aware File System предназначена для согласованной работы нескольких Nodes с общим Block Storage.

Другой вариант — предоставить право записи только активному Node Failover Cluster.

SAN и Backup

SAN не является Backup.

Даже если Storage Array имеет RAID и два Controllers, пользователь может удалить данные, а Ransomware — зашифровать их.

Для восстановления прошлой версии нужна независимая копия.

Snapshot в SAN

Storage Snapshot фиксирует состояние LUN или Volume в определенный момент.

Он может использоваться для быстрого восстановления и создания Backup Workflow.

Snapshot не заменяет Backup

Если Snapshot находится на том же массиве, отказ или компрометация всей Storage System может затронуть и его.

Критичные данные должны иметь независимые копии.

Storage Replication

Replication копирует данные на второй Array:

Primary SAN
↓ replication
Secondary SAN

Вторая система может находиться в другом дата-центре.

Synchronous Replication

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

Это уменьшает потенциальную потерю последних данных, но требует низкой Network Latency.

Asynchronous Replication

При асинхронной схеме изменения отправляются на вторую площадку позже.

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

SAN и Disaster Recovery

Репликация SAN может быть частью DR Architecture, но необходимо также иметь:

• вычислительные ресурсы;
• Network Configuration;
• Application Recovery Plan;
• DNS или Routing Switch;
• регулярные тесты восстановления.

Replication не является историческим Backup

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

Поэтому нужны Snapshots и Backup с Retention.

Thin Provisioning

Thin Provisioning позволяет выделить Server логический Volume большего размера, чем физически занято в данный момент.

Storage Capacity выделяется по мере записи данных.

Пример Thin Provisioning

Logical LUN: 10 TB
Actual written data: 2 TB
Physical space consumed: approximately 2 TB plus overhead

Это повышает эффективность использования Storage.

Риск Thin Provisioning

Если несколько Volumes начинают быстро расти, физический Storage Pool может закончиться.

Поэтому необходим Capacity Monitoring.

Thick Provisioning

При Thick Provisioning место резервируется заранее.

Это дает более предсказуемое Capacity Planning, но может менее эффективно использовать свободную емкость.

Deduplication

Storage Array может находить одинаковые Blocks и хранить один экземпляр вместо множества копий.

Это особенно эффективно для похожих Virtual Machines и некоторых типов Backup.

Compression

Compression уменьшает физический объем данных.

Степень экономии зависит от Workload: уже сжатые Media Files уменьшаются значительно хуже обычных текстовых или Database Blocks.

Data Reduction

Совокупность Deduplication и Compression часто называют механизмами Data Reduction.

При Capacity Planning важно отличать физическую емкость от логически предоставленного объема.

SAN и шифрование

Шифрование может применяться:

• на уровне дисков массива;
• на уровне Storage Controller;
• на уровне Host;
• на уровне Database или Application.

Каждый уровень решает свою часть задачи.

Encryption at Rest

Шифрование данных на накопителях защищает от чтения информации при физическом извлечении дисков или утилизации оборудования.

Encryption in Transit

Для некоторых SAN Technologies доступны механизмы защиты Storage Traffic при передаче.

Особенно это важно, если Storage Network проходит через менее доверенную инфраструктуру.

SAN и Zero Trust

SAN традиционно строится как изолированная инфраструктура, но сам факт нахождения Server внутри дата-центра не должен автоматически давать ему доступ ко всем LUN.

Zoning, LUN Masking и строгая Authentication уменьшают избыточное доверие.

SAN и Least Privilege

Database Server должен видеть только свои Storage Volumes.

Backup Server — только те Resources, которые необходимы его функции.

Избыточная видимость LUN увеличивает риск ошибки Administrator и компрометации.

SAN и Network Segmentation

iSCSI Traffic обычно отделяют от пользовательской LAN.

User LAN
Management LAN
Storage VLAN
Backup Network

Это помогает изолировать Storage и предсказуемо управлять производительностью.

SAN и VLAN

Для iSCSI VLAN помогает логически разделить Storage Traffic, но для критичной инфраструктуры также важны физическая Redundancy, ACL и отдельные Interfaces.

SAN и Firewall

В IP-based SAN Firewall или ACL может ограничивать доступ к Storage Interfaces.

При этом правила должны учитывать требования к Performance и High Availability.

SAN и RBAC

Management Console Storage System должна использовать Role-Based Access.

Например:

Storage operator → monitor and provision
Storage admin → configuration
Auditor → read-only logs

Не каждому оператору необходим полный Administrator Access.

SAN и PAM

Storage Administrator имеет чрезвычайно широкие полномочия и может удалить LUN или Snapshot.

Поэтому административный доступ к SAN целесообразно защищать MFA, PAM и Session Audit.

SAN и MFA

MFA особенно важна для Management Interface и удаленного административного доступа.

Одна украденная учетная запись не должна давать полный контроль над корпоративным Storage.

SAN и DLP

DLP контролирует использование и вывод чувствительных данных, а SAN только предоставляет Storage.

SAN не определяет, можно ли сотруднику отправить файл во внешнюю почту.

SAN и Ransomware

Если Application или Server имеет Write Access к LUN, Ransomware может изменить данные на SAN через этот Server.

Storage Array видит такие операции как легитимные записи.

Защита SAN от Ransomware

Полезны:

• Immutable Snapshots;
• отдельные Backup Credentials;
• Least Privilege;
• Storage Replication с защитой от удаления;
• PAM;
• EDR на Servers;
• Network Segmentation.

Immutable Snapshot

Неизменяемый Snapshot нельзя удалить или модифицировать обычной административной операцией до окончания заданного Retention Period в поддерживаемой реализации.

Это создает дополнительный Recovery Layer.

SAN и Monitoring

Необходимо контролировать:

• Controller Health;
• Disk Health;
• Port Status;
• Path Failures;
• Latency;
• IOPS;
• Throughput;
• Capacity;
• Cache;
• Replication.

Почему важен Path Monitoring

Multipathing может скрыть отказ одного Link от пользователей.

Система продолжит работать по второму пути, но Redundancy уже потеряна.

Без Alert проблема обнаружится только после второго отказа.

SAN и Zabbix

Monitoring Platform может получать Storage Metrics через SNMP, API или Vendor Integration и создавать Alerts по Capacity и Hardware Failures.

SAN и Observability

При медленной работе Application важно видеть связь между Host, LUN и физическим Storage Pool.

Высокая Database Latency может быть вызвана не Database Engine, а перегруженным Array.

SAN и SIEM

Security Events Management Console можно передавать в SIEM.

Особенно важны:

• Administrator Logins;
• изменение LUN Masking;
• создание и удаление Volumes;
• удаление Snapshots;
• изменение Replication;
• Firmware Changes.

SAN и SOC

SOC обычно не управляет Storage Performance, но при Security Incident может анализировать административные события массива и попытки удалить Recovery Copies.

Firmware SAN

Storage Controllers и Switches работают под специализированным Software и Firmware.

Они требуют Patch Management так же, как Servers и Network Devices.

SAN и CVE

Уязвимостям Management Interface, Storage OS и SAN Switch Firmware могут присваиваться CVE.

Особенно важно ограничивать Administrative Network Access к таким устройствам.

Management Network

Управление SAN желательно отделять от пользовательского и Storage Traffic.

Management workstation
↓ management network
Storage console

Management Interfaces не должны быть доступны обычным пользователям.

Out-of-band Management

Отдельный Management Path позволяет управлять Storage даже при проблемах основной Data Network.

Он должен иметь собственные Security Controls.

Firmware Update SAN

Корпоративные массивы часто поддерживают обновления с минимальным Downtime за счет Redundant Controllers.

Однако перед обновлением необходимо проверить Compatibility с HBA Drivers, Multipath Software и Operating Systems.

Interoperability

SAN состоит из компонентов разных уровней:

• Server OS;
• HBA;
• Driver;
• SAN Switch;
• Storage Controller;
• Firmware.

Некорректная комбинация версий способна приводить к нестабильности, поэтому важны Vendor Compatibility Matrices.

SAN и Capacity Planning

При планировании учитывают не только свободные терабайты, но также:

• рост данных;
• Snapshots;
• Replication;
• Data Reduction;
• Backup;
• необходимый резерв производительности.

Почему 100% заполнение Storage опасно

Некоторым Storage Functions требуется свободное пространство для Snapshots, Metadata и внутренних операций.

Кроме того, Thin Provisioning при полном Pool может привести к серьезным сбоям приложений.

Oversubscription

При Thin Provisioning суммарный логический объем LUN может превышать физическую емкость Array.

Это нормально только при постоянном Monitoring и прогнозировании роста.

SAN и масштабирование

Storage можно расширять:

• добавлением дисков;
• добавлением Shelves;
• заменой накопителей;
• созданием нового Storage Pool;
• добавлением второго массива.

Scale-up SAN

Scale-up означает увеличение ресурсов одного Storage Array.

Например, добавление дисковых полок.

Scale-out Storage

Scale-out архитектура увеличивает емкость и производительность добавлением Nodes.

Она может использовать распределенные Storage Technologies и отличаться от классической двухконтроллерной SAN.

SAN и Software-defined Storage

Современные инфраструктуры могут предоставлять Block Storage программно на группе стандартных Servers.

Функции, ранее характерные только для специализированных SAN Arrays, реализуются Software Layer.

SAN и Ceph

Распределенные Storage Platforms могут предоставлять Block Devices, File Storage и Object Storage без классического аппаратного SAN массива.

Это альтернативная архитектура централизованному Storage.

SAN и Cloud

В Public Cloud пользователь обычно получает виртуальный Block Storage Service без управления физической SAN Infrastructure.

Концептуально приложение все равно работает с удаленным блочным диском, но Fabric и Hardware обслуживает Cloud Provider.

SAN и Object Storage

Object Storage предоставляет Objects через API, а SAN — Block Devices.

Это разные модели:

SAN и Backup Storage

Backup Repository не всегда выгодно размещать на той же дорогой SAN, что Production Database.

Backup Workload может требовать большой емкости, но не такой низкой Latency.

Поэтому для него часто используют отдельный Storage Tier.

SAN как Single Point of Failure

Если все Business Systems зависят от одного Storage Array, его полный отказ способен остановить значительную часть инфраструктуры.

Поэтому критичный SAN проектируют с Redundancy и DR.

Полный отказ Storage Array

RAID не защищает от всех возможных отказов:

• Firmware Corruption;
• ошибка Administrator;
• отказ нескольких компонентов;
• пожар;
• проблема электропитания;
• логическое повреждение данных.

Для этих сценариев нужны Backup и Replication.

Типичные ошибки при проектировании SAN

1. Использовать один Network Path.
2. Не настраивать Multipathing.
3. Подключать Storage Traffic к перегруженной пользовательской LAN.
4. Считать RAID резервной копией.
5. Не контролировать Latency.
6. Игнорировать Thin Provisioning Capacity.
7. Давать Servers доступ к ненужным LUN.
8. Не обновлять Firmware.
9. Не проверять Compatibility.
10. Не тестировать отказ компонентов.

Как спроектировать SAN

Шаг 1. Определить Workload

Рассчитайте IOPS, Latency, Throughput и Capacity для Applications.

Шаг 2. Выбрать Storage Protocol

Например, Fibre Channel, iSCSI или более современную архитектуру в зависимости от требований.

Шаг 3. Устранить Single Points of Failure

Используйте несколько Controllers, Switches, Links и HBA.

Шаг 4. Настроить Multipathing

Server должен корректно переживать отказ отдельного пути.

Шаг 5. Настроить Access Control

Используйте Zoning и LUN Masking.

Шаг 6. Разделить Workloads

Критичная Database не должна бесконтрольно конкурировать с Backup Jobs.

Шаг 7. Настроить Monitoring

Контролируйте Capacity, Latency, Paths и Hardware.

Шаг 8. Создать Backup и DR

Storage Redundancy не отменяет независимого восстановления.

Как выбрать между SAN и NAS

Если основной сценарий — совместные документы пользователей, обычно естественнее File Storage вроде NAS.

Если Server требуется блочный диск для Database, Virtualization или Cluster, SAN может быть более подходящей моделью.

Когда SAN может быть избыточной

Для небольшой компании с несколькими общими папками сложная Fibre Channel Infrastructure может быть экономически неоправданной.

NAS или простой iSCSI Storage может решить задачу дешевле и проще.

Когда SAN оправдана

SAN особенно полезна, когда:

• десятки Servers используют Shared Storage;
• важна низкая Latency;
• используется крупная виртуализация;
• нужны Failover Clusters;
• требуется централизованное управление Storage;
• Downtime критичен для бизнеса.

Метрики SAN

Практический пример

Компания использует кластер виртуализации из четырех серверов. На каждом Host работает несколько десятков виртуальных машин.

Если VM Disks хранить только на локальных дисках Hosts, перенос виртуальной машины между серверами усложняется.

Компания устанавливает централизованный Storage Array и строит два независимых SAN Paths.

Hypervisor 1 ─┐ Fabric A ─┐
Hypervisor 2 ─┼────────────────┼→ Storage array
Hypervisor 3 ─┼────────────────┤
Hypervisor 4 ─┘ Fabric B ─┘

Каждый Host имеет два независимых подключения и использует MPIO.

Storage Administrator создает LUN для Cluster и ограничивает доступ только WWN этих четырех Hosts.

Virtual Machines размещаются на общем Storage, поэтому при отказе одного Hypervisor их можно запустить на другом Server.

Одновременно система мониторинга контролирует Latency и Path Status.

Если один SAN Switch выходит из строя, I/O автоматически продолжает идти через вторую Fabric.

Отдельно Storage Replication копирует критичные данные во второй дата-центр, а Backup System создает исторические резервные копии.

Таким образом, SAN решает задачу общего высокодоступного Block Storage, но Backup и Disaster Recovery остаются отдельными уровнями защиты.

SAN для бизнеса

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

Для крупной инфраструктуры это упрощает Virtualization, Capacity Management и High Availability.

Но SAN значительно сложнее обычного файлового хранилища. Ошибки Zoning, Multipathing, Capacity Planning или Firmware Compatibility способны затронуть сразу множество систем, поэтому Storage Infrastructure требует специализированного администрирования и постоянного Monitoring.

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

• высокопроизводительный Block Storage;
• централизованное управление емкостью;
• общий Storage для Clusters;
• поддержка Multipathing;
• Storage Snapshots и Replication;
• удобство для Virtualization и Database;
• возможность масштабирования.

Ограничения SAN

• выше сложность инфраструктуры;
• стоимость оборудования и поддержки;
• требуются специализированные навыки;
• ошибка Storage может затронуть много Servers;
• не заменяет Backup;
• нуждается в тщательном Capacity Planning;
• требует контроля Compatibility и Firmware.

Связанные термины

Краткий итог

SAN — Storage Area Network, специализированная сеть, предоставляющая Servers централизованный Block Storage. В отличие от NAS, сервер получает не готовую сетевую папку, а логическое блочное устройство, на котором самостоятельно размещает File System, Database или Virtual Machine Storage.

SAN может строиться на Fibre Channel, iSCSI и других технологиях. Для корпоративной инфраструктуры особенно важны LUN, Zoning, Multipathing, несколько независимых Paths, Storage Controllers и постоянный Monitoring Latency и Capacity.

SAN широко применяется в виртуализации, базах данных и Failover Clusters, но высокая доступность массива не заменяет резервное копирование. Надежная архитектура сочетает SAN с RAID или другими механизмами избыточности, Snapshots, Backup, Replication и Disaster Recovery.