Можно ли использовать iSCSI для хранения картинок для сайта?

Question

[grabbee]

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

Answer 1

[Владимир]

iSCSI - один из стандартов в индустрии по предоставлению места с СХД потребителям, повсеместно используется в виртуализации например. Если у вас отдельная сетевая карта 10 гигабит, а лучше две в бонде, мту 9000 то у вас будет все хорошо, и вы врядли упретесь в гораничения iSCSI, скорее исчерпаете лимиты скорости и операций ввода/вывода (IOps) вам предоставит СХД.

Comments

[Максим Корнеев]

а что за провайдер где Вы работаете? ну чтобы никогда к нему не попасть на таких специалистов.

[Владимир]

Максим Корнеев, из вашей реплики я вижу только "наезд" а вот в чем я не прав вы не удосужились написать, пожалуста обоснуйте ваше мнение - что не так с моим комментарием, возможнно у нас просто абсолютно разный опыт эксплуатации СХД и области применения этих СХД.

[Максим Корнеев]

Владимир, Вы написали ахинею от начала до конца. мутный бессмысленный поток обрывков знаний из разных областей. Вопрос был про SAN, в ответ Вы рассказываете про MTU и 10Гб на бекэнде. не говоря уже о том, что клиент из своей консоли скорее всего видит (если вообще видит) только виртуальные предоставленные ему устройства и знать не знает ни про каие бонды.
упереться в ограничение iSCSI - плевое дело, и даже Вы сами в своем посте об этом пишите.
ну и превысить лимит дисковых операций сайтом с картинками... мне страшно за Ваших клиентов, из чего вы там хостинг то собрали?

[Владимир]

Максим Корнеев, Автор вопроса спрашивает про iSCSI, упоминает сервер и отдельную сетевую карту, если у него более менее посещаемый ресурс(сайт) то возможно у него выделенный сервер (bare metal) и раз автор задает такие вопросы то там нет поддержки которая "сделает все хорошо" то ему придется изучать утилиту iscsiadm и так далее.
Ваша поспешность выводов меня огорчает, мы незнаем какой сайт у клиента - может это чтото типа джойреактора с огромной посещаемостью, и мы незнаем что за SAN ему предлагают, может там просто много места и обычные sata hdd.
И так как вы второй комментарий подряд делаете нападки - конструктивной беседы не получается поэтому я больше не вижу смысла вам отвечать.

[grabbee]

Владимир, да, сервер выделенный. Железка от крупного поставщика в датацентре. С двумя сетевыми портами. Один внешний, второй внутренний. Для нищебродов поставляется 2,5Гб с возможностью расширить внутренний порт до 10Гб. Он же предоставляет SAN c подключением по этой внутренней сетевой карте. Для меня 2,5Гб и если нужно будет за доп стоимость расширят до 10. Поддержки нет от слова совсем. Максимум что сделают - потушат сервер огнетушителем, или отключат от сети.

Тема для меня новая. Мне стало интересно вынести хранение картинок на отдельную систему. Хостер предоставляет HA-SAN с резервированием в два дата центра и легкое наращивание дискового пространства. И обещают до 10Гб канал для данных. Меня этот вариант заинтересовал. Так как эта скорость похоже выше даже чем у SATA диска внутри самого сервера. Как я смог понять из того что успел изучить - этого достаточно для большинства задач моего уровня.

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

[grabbee]

Максим Корнеев, да мне дают только доступ к готовому LUN. Канал 2,5Gbps без лимитов ни на трафик ни на операции. Делай что хочешь в своих 2,5Gbps но за доп деньги докинут до 10Gbps

[Владимир]

grabbee, скорость SAN будет зависеть от типа рейд массива, от количества дисков и их характеристик + колво потребителей этого SAN, если это не дорого то возьмите на месяц протестирывать, в случае достаточной скорости это снимет с вас головную боль о количестве места, рейд массивах и заменах дисков.
Для больших проэктов где много статики обычно разделяют что где хранится, например самые посещаемые вроде главной страницы сайта и какието топ новости могут лежать целиком в памяти в кеше nginx или например в ramdisk(обязательно с копией на локальном диске), дальше менее популярные вещи на локальном ssd/nvme и старые материалы например на медленно но обьемном SAN

[Максим Корнеев]

Владимир, перестаньте путать человека и выберетесь уже из прошлого века. рейды давным давно собирают не из дисков, а на дисковых пулах и на скорость типы рейда давно никак не влияют, только на то сколько дисковых полок может потерять хостер сохранив данные и производительность. а правильно собранную на FC SAN сеть упаритесь просаживать, например сберу это не удается - упираются а производительность СХД, а не в сеть. все это просчитывается на этапе планирования. ну у современных нормальных хостеров, во всяком случае. и в договоре вроде бы цыферьки гарантированной производительности должны быть указаны, иначе за что денешка то берется? а "месяц тестирования" просто смешно - десяток кликов мышкой для настройки тиринга и кеша и на любом месяце скорость может упасть на порядки если не прописана в договоре.
а nginx нужен не чтобы в кеше держать, а для распределения нагрузки и если до этого дошло то надо на микросервисы с автоматическим масштабированием сервисов в зависимости от нагрузки переходить а не локально нвме засовывать.

Answer 2

[Максим Корнеев]

Если иэто дублированный вопрос о LUN - то производительности Вам скорее всего хватит. Другой вопрос, как Вы храните контент - в СУБД или фалами. LUN это блочный доступ который ориентирован на СУБД, если контент лежит в базе данных - все будет просто замечательно. Если же Вы храните контент файлами - имеет смылс искать хостера с файловым доступом или смотреть другие тарифы у это же хостера в которые входит файловый доступ, а не блочный.
В любом случае iSCSI это протокол работы сервера с СХД и от него Вы не уйдете пока не арендуете бареметал сервер с достаточной дисковой емкостью без подключаемого внешнего СХД. А это скорее всего будет дороже текущего тарифа.

Comments

[grabbee]

Файлы отдельные. В БД только имя файла. Они только SAN дают по iSCSI - сервер с достаточным диском не проблема. Мне стало интересно вынести картинки в отдельный "сервис" - чтобы не париться с местом на диске и чтобы можно было переключить аварийный сервер на резервный без необходимости таскать файлы картинок туда-сюда. Тем более они предлагают в том числе HA-SAN с резервированием в два ДЦ. Это кажется будет более стабильнее чем диск на выделенном сервере.

[Максим Корнеев]

grabbee, у Вас скорее всего асинхронная репликация лунов? в случае аварии типичное решение - останавливается сервис (сайт в данном случае), вручную отмапливается отключившийся LUN и примапливается рабочий и сервис запускается. после восстановления основного ДЦ производится обратная операция. Луны в обратную сторону должен синхронизировать хостер, как правило это происходит автоматически. эта схема когда сервис развернут на третьей площадке и он не зависит от состояния ДЦ где лежат данные.

если вам доступно создание лунов, то кто настраивает репликацию на удаленную площадку и производит переключение репликации после аварии?

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

[grabbee]

Максим Корнеев, они всё сами делают. Мне только логин к цели дают и выделенное место. Что это значит на практике я не знаю. Нет опыта совсем.

[Максим Корнеев]

grabbee, это значит репликацию (резервироание) на удаленную площадку кто-то настроит. при репликации задается исходное СХД и целевое (резервное). репликация работает всегда в одну сторону. на целевой лун, если репликация не актив-актив, запись недоступна. у вендоров обычно есть софт который автоматически отслеживает доступность площадок и при падении основной переключает целевую в исходную делая доступной запись. ну или это делается вручную. после этого возможно переключение сервиса на работу с резервным ДЦ. при восстановлении основной площадки репликация включается в обратную сторону. когда она завершится для возврата на первую плозадку (если это нужно, например для резервирования часто используют менее производительное оборудование для экономии, не факт что в вашем случае это так, у хостера оба ДЦ могут быть одинаковыми) надо остановить сервис, остановить репликацию, переподключить сервис на первую площадку, поменять направление репликации и включить ее после этого запустить сервис. (звучит муторно, но я писал это дольше чем это делать) если репликация актив-актив то переключение между площадками возможно в любой момент.

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