Я не уверен, что это правильный форум, но вот ...
Мой работодатель решил установить SAN. По разным не относящимся к делу причинам этого на самом деле не произошло. Но я провел небольшое исследование, чтобы выяснить, что такое «SAN», и ... я сбит с толку. Похоже на такой абсурдно плохая идея что я могу только сделать вывод, что я неправильно понял, как это работает.
Насколько я могу судить, SAN означает сеть хранения данных, и это в основном означает, что вы подключаете свои серверы к своим дискам, используя обычную IP-сеть. Я совершенно потрясен тем, что любой здравомыслящий человек может подумать, что это хорошая идея.
Итак, у меня есть мой сервер, подключенный к его дискам с помощью канала Ultra-320 SCSI. Это 320 МБ / с пропускной способности, распределяемой между всеми дисками на этом сервере. А затем я отрываю их от канала SCSI и подключаю к сети Ethernet со скоростью 100 Мбит / с с теоретической пропускной способностью 12,5 МБ / с. Это перед вы принимаете во внимание любые задержки маршрутизации, накладные расходы IP и, возможно, конфликты пакетов. (Последнего обычно можно избежать.)
320 МБ / с, стихи 12,5 МБ / с. Это, позвольте мне посмотреть, примерно в 25 раз медленнее. На бумаге. Прежде чем мы добавим накладные расходы на IP. (Предположительно у SCSI есть свои собственные командные издержки, но я угадывать SAN, вероятно, просто туннелирует команды SCSI по IP, а не реализует совершенно новый дисковый протокол по IP.)
Теперь, когда каждый сервер имеет выделенный канал SCSI, это означает, что каждый раз, когда я добавляю еще один сервер, я увеличиваю пропускную способность (и больше дисков). Но с общим SAN каждый раз, когда я добавляю сервер, я забирая пропускную способность с существующих серверов. Вещь теперь получает помедленнее поскольку я добавляю больше оборудования, а не Быстрее.
Кроме того, очевидно, что технология SAN чрезвычайно дорога. И кажется разумным предположить, что настройка всей IP-сети намного сложнее, чем просто подключить несколько дисководов к кабелю.
Итак, это недостатки использования SAN - значительное увеличение стоимости, значительное снижение производительности, потеря масштабирования, повышенная сложность и другие возможные точки отказа системы. Так в чем же преимущества?
Я все время слышу, что это упрощает добавление дисков или перемещение диска с одного сервера на другой. Который звуки достаточно логично - по-видимому, с SAN вам просто нужно нажать несколько кнопок, и теперь диск принадлежит другому серверу. Это намного проще, чем физически перемещать диск (в зависимости от того, как именно ваши диски подключены).
С другой стороны, за 10 лет работы здесь мне пришлось менять диски ... дай посчитать ... дважды. Так что это событие происходит примерно раз в 5 лет. Так вы говорите мне, что раз в 5 лет SAN сэкономит мне 5 минут работы? И каждую секунду каждого дня это будет делать вещи в 25 раз медленнее? И это хороший компромисс?
Думаю, если бы я отвечал за какой-нибудь огромный дата-центр с тысячи серверов, отслеживать такой объем диска может быть сложно, а наличие SAN может иметь смысл. Черт возьми, если все серверы виртуализированы, они все равно будут чертовски медленными, так что, возможно, SAN даже не будет иметь значения.
Однако это совершенно не соответствует моей ситуации. у меня есть два серверы с три диски каждый. Не то чтобы управлять всем этим «сложно».
Короче говоря, как бы я ни смотрел на это, это выглядит крайне глупо. На самом деле это выглядит так очевидно глупо, что никто не тратит время на исследования и разработки, делая что-то настолько глупое. Как я уже сказал выше, это может означать только то, что я где-то неправильно понимаю - потому что никто не будет делать что-то настолько глупое.
Может ли кто-нибудь объяснить мне, чего я здесь не вижу?
Чего вы здесь не видите, так это того, что, хотя никто в здравом уме не будет использовать 100 Мбит Ethernet для обработки трафика SAN, существует множество других вариантов, которые не только быстрее, но и намного быстрее, чем хранилище с прямым подключением ( как стандартный SCSI).
Сети SAN корпоративного уровня обычно подключаются к серверам с помощью Fibre Channel технология, скорость которой составляет от 1 Гбит до 20 Гбит, с наиболее часто используемыми адаптерами в диапазоне 4-8 Гбит; это не только позволяет впечатляющий пропускная способность, но также может использовать Многопутевый ввод / вывод, позволяя агрегировать полосу пропускания и переключаться между различными адаптерами, коммутаторами FC и контроллерами хранилища для максимальной доступности.
Другой способ доступа серверов к хранилищу SAN - использование iSCSI, который является реализацией протокола SCSI поверх IP-транспорта; это, вероятно, то, что вы имели в виду в своем вопросе. На самом деле это часто считается неоптимальным решением (оптимальным является FC), но все равно никто не будет запускать его через 100 Мбит Ethernet, и все меняется. резко при запуске по гигабитному (или 10 Гбит) каналу Ethernet.
Что касается скорости, то все, что вы слышали о SAN, применимо: вы можете создавать тома и изменять их размер (так называемый LUN-ы) по запросу, предоставлять их на разные серверы (даже более чем на одном одновременно, что обычно является требованием для кластеризации), а также иметь некоторые приятные дополнительные преимущества, такие как репликация SAN-to-SAN и резервное копирование на уровне SAN, которые могут действительно измените ситуацию, когда вам нужно обеспечить высокую доступность и аварийное восстановление для больших (например, многих ТБ) данных.
Как обычно, копать можно дальше: http://en.wikipedia.org/wiki/Storage_area_network.
Конечно, это обычно имеет смысл для средних / больших сред. Небольшой SAN может быть даже в небольших. Но в месте с два сервера, любой вид SAN, скорее всего, будет излишним.
Уверяю вас, мы далеки от сумасшествия, давайте рассмотрим несколько ваших мыслей.
это в основном означает, что вы подключаете свои серверы к своим дискам, используя обычную IP-сеть.
Вы жестяная банка делают это, но многие этого не делают, для повышения производительности и надежности у многих есть выделенные сети только для Data Center Ethernet (для FCoE), IP (для iSCSI) или связи на основе Fibre Channel (FC) со своими массивами.
Ultra-320 SCSI на самом деле составляет всего 2,560 Гбит / с, в то время как Ethernet 1 Гбит / с (как часто используется для iSCSI), следовательно, в 2,56 раза медленнее в целом, многие люди счастливы справиться с этим ограничением, поскольку их требования к пропускной способности соответствуют этому профилю. Но SAN очень часто работают с НАМНОГО более быстрых протоколов, каналы Ethernet 10 Гбит / с, 40 Гбит / с и 100 Гбит / с используются как для FCoE, так и для iSCSI, а в мире FC большинство скоростей каналов составляет 4 Гбит / с, 8 Гбит / с и 16 Гбит / с - лучше всего, протоколы FC и FCoE специально разработаны для обрабатывают данные хранилища и деградируют намного более плавно при высокой одновременной нагрузке, чем при использовании обычного Ethernet или SCSI / SAS. Между прочим, никто бы никогда не стал использовать Ethernet 100 Мбит / с для iSCSI в производственной среде, а кто в наши дни вообще использует Ethernet 100 Мбит / с?
Таким образом, SAN очень часто могут быть намного быстрее, чем локально подключенное хранилище, но основная причина, по которой люди используют SAN, - это обеспечение бесперебойной работы своих служб. Они делают это, используя совместное использование на уровне блоков и файловые системы с поддержкой кластеров, более чем один сервер может иметь одновременный доступ к отдельным блокам данных одновременно, а не к файлам, как при использовании NAS. Вот как у нас, профессионалов, могут быть многоузловые кластеры БД и отказоустойчивые виртуальные машины.
И, как вы предлагаете, намного проще добавлять, менять и удалять диски - если мне нужно использовать локальный диск, мне нужно заказать физический диск, установить его и представить его машине. С SAN у меня уже есть один большой блок дисков, и я просто делю то, что мне нужно, по мере необходимости, представляя его за секунды на сервер по мере необходимости, когда это не нужно, пространство возвращается в пул. Кроме того, отказавшие диски обрабатываются гораздо более плавно.
Я думаю, что ваша проблема в том, что у вас нет опыта работы с масштабом, я отвечаю за десятки тысяч дисков, они умирают каждый день, но у нас очень плавный процесс, который включает в себя глобальные онлайн-запчасти, которые устанавливаются на свои места по мере необходимости, Это означает, что мы можем заменять физические диски в обычное рабочее время - нет необходимости в ночных звонках. Если бы я просто присматривал за несколькими автономными устройствами, я бы тоже ничего не понял, но для предприятий с важными требованиями к доступности, меняющимися потребностями и надежным хранением больших объемов данных, я боюсь, что SAN - единственное, что имеет смысл .
Хорошо, во-первых, обычно вы используете san в сетях со скоростью более 100 Мбит / с. 1 гиг, 10 гиг или (чаще всего) FibreChannel.
Чтобы перейти к удобству использования, большинство серверов теперь виртуализированы. У вас есть (например) 10 хостов, на которых размещено 100 виртуальных машин. Если машины на одном хосте начнут использовать слишком много ЦП, что вы собираетесь делать? ... перенести их? Как вы себе представляете это с локальными дисками? Скопировать все данные (скажем, 100 гигов на машину) на другой хост, а потом обратно? Вот почему вы подключаете все хосты к большой сети SAN, храните там все данные и просто отправляете информацию о рабочем состоянии машины.
Также существует возможность более эффективного использования хранилища - например, DNS-серверу обычно требуется очень мало места на диске (если журналы отправляются в другое место), но другим службам (файловым серверам) требуется много. Если вы объедините их все в большом SAN, вы можете сэкономить место, используя все имеющиеся там диски (даже свободное место на диске, которое в противном случае было бы на DNS-сервере).
О безопасности данных - сколько у вас дисков? Диски выходят из строя ... очень много! Если вы хотите, чтобы службы работали, вам нужен хотя бы какой-то уровень RAID (обычно raid1 или 5 или любая другая комбинация). Итак, вы DNS-сервер из предыдущего примера, вам нужны 2 диска по 400 ГБ (если вы покупаете новый сервер, обычно вы не можете получить меньше этого, если только вы не покупаете ssd). Таким образом, каждому серверу требуется x2 диска (или n + 1 для raid5).
В среде SOHO использование SAN - это полный перебор. В корпоративной среде вы действительно, действительно хотите иметь централизованное хранилище, по крайней мере для виртуальных машин, и централизованное управление оборудованием для них.
Ваш пост слишком длинный, честно говоря, я не собираюсь его читать (извините), но да, вы упускаете некоторые моменты;
Итак, у меня есть мой сервер, подключенный к его дискам с помощью канала Ultra-320 SCSI. Это 320 МБ / с пропускной способности, распределяемой между всеми дисками на этом сервере. А затем я отрываю их от канала SCSI и подключаю к сети Ethernet со скоростью 100 Мбит / с с теоретической пропускной способностью 12,5 МБ / с.
Да, тогда используйте сетевую структуру 10 Гбит / с. Добавьте несколько интерфейсов 10Gig и свяжите их, если хотите, получите 40 Гбит / с. Ответ простой. Если вам нужна пропускная способность более 100 Мбит / с, не используйте сетевое оборудование 100 Мбит / с.
Теперь, когда каждый сервер имеет выделенный канал SCSI, это означает, что каждый раз, когда я добавляю еще один сервер, я увеличиваю пропускную способность (и больше дисков).
Выделенная ссылка SCSI на какой модуль хранения? Или RAID-контроллер?
Но с общей SAN каждый раз, когда я добавляю сервер, я забираю полосу пропускания у существующих серверов. Теперь по мере добавления оборудования все становится медленнее, а не быстрее.
Нет, опять же, добавьте больше интерфейсов к вашим томам хранения и добавьте больше томов хранения. Если у вас есть дисковый массив с выделенным каналом SCSI к серверу, и вы добавляете еще один сервер с выделенным каналом SCSI к массиву дисков, теперь вы разделили полосу пропускания для каждого сервера пополам (если только блок хранения не может работать в два раза больше быстро, как канал SCSI!).
Довольно редко люди запускают устройства со 100% нагрузкой днем и ночью, пропускная способность - гораздо меньшая проблема по сравнению со временем поиска и задержкой. Похоже, вы увлечены чисто архитектурными проблемами, которые легко преодолеть.
Однако это совершенно не соответствует моей ситуации. У меня два сервера по три диска. Не то чтобы управлять всем этим «сложно».
Да, SAN не для вас.
Если бы у вас было хотя бы 10 серверов с 10 виртуальными машинами на каждом, вы бы хотели, чтобы они хранились в SAN. Если все данные хранятся локально на сервере, когда этот сервер выйдет из строя, данные будут отключены. Сети SAN повышают доступность данных за счет репликации на другие узлы хранения. Они также улучшают целостность с помощью централизованных снимков, резервных копий и контрольных сумм.
Как только у вас появляется большое количество серверов, локальное хранилище быстро становится слишком затратным и сопряженным с риском для управления.
Я не говорю, что они лучшие, так как нарезанный хлеб и работают в любой ситуации, особенно учитывая потенциальную стоимость. Вам действительно нужно прочитать книгу, которую я думаю о SAN, например вот этот, это прояснит ситуацию.
Вы, кажется, смотрите на необработанный доступ на сервере. Если у вас есть сервер, который использует много дискового ввода-вывода, тогда имеет смысл напрямую подключать хранилище вместо хранилища через 100-мегабитный Ethernet.
Тем не мение:
1) Посмотрите на роль файлового сервера:
Clients <-> Ethernet <-> [ fileserver HW -> SCSI/SAS -> disks ]
Теперь в вашем SAN
Clients <-> Ethernet <-> [ Some hardware, probably with SAS and disks ]
Сейчас все не так иначе. :)
2) Скорость сети
Есть довольно много более быстрых интерфейсов, чем 100-мегабитный Ethernet. Может быть, не в версии для дома / SOHO. Но корпоративная SAN будет предлагать такие вещи, как FibreChannel, iSCSI, 10GBit Ethernet и т. Д.