grabbee,
когда я спрашивал это у более опытных товарищей мне сказали что LUN подключить к двум хостам можно, но примаплен он должен быть только на одном. тоесть сделать так можно, сработает, но риск потерять все слишком велик.
разделы, ФС, файлы существуют только на уровне сервера. до СХД по iSCSI доходит только поток блоков данных и команд. что произойдет когда два сервера которые ничего не знают про то что у них общий диск (а LUN они видят как локальное блочное устройство) запишут в него данные - непредказуемо. SCSI - протокол 1978 года стех пор там поменялось только количество подключаемых устройств и добавилась инкапсуляция в IP (iSCSI - SCSI over IP). тогда так подключали локальные диски. тоесть там в принципе не предусмотрена возможность обращения к одному LUN разных хостов.
Владимир, перестаньте путать человека и выберетесь уже из прошлого века. рейды давным давно собирают не из дисков, а на дисковых пулах и на скорость типы рейда давно никак не влияют, только на то сколько дисковых полок может потерять хостер сохранив данные и производительность. а правильно собранную на FC SAN сеть упаритесь просаживать, например сберу это не удается - упираются а производительность СХД, а не в сеть. все это просчитывается на этапе планирования. ну у современных нормальных хостеров, во всяком случае. и в договоре вроде бы цыферьки гарантированной производительности должны быть указаны, иначе за что денешка то берется? а "месяц тестирования" просто смешно - десяток кликов мышкой для настройки тиринга и кеша и на любом месяце скорость может упасть на порядки если не прописана в договоре.
а nginx нужен не чтобы в кеше держать, а для распределения нагрузки и если до этого дошло то надо на микросервисы с автоматическим масштабированием сервисов в зависимости от нагрузки переходить а не локально нвме засовывать.
LUN мапится в линухе:
ставите open-iscsi или iscsi-initiator-utils, зависит от версии линуха, погуглите под ваш.
iscsiadm -m discovery -t st -p "адрес_хоста"
iscsiadm -m discovery -m node -l
hot_add
fdisk -l
и смотрите каким устройством он подключился
создаете раздел/ы и ФС.
и мапите
grabbee, у Вас скорее всего асинхронная репликация лунов? в случае аварии типичное решение - останавливается сервис (сайт в данном случае), вручную отмапливается отключившийся LUN и примапливается рабочий и сервис запускается. после восстановления основного ДЦ производится обратная операция. Луны в обратную сторону должен синхронизировать хостер, как правило это происходит автоматически. эта схема когда сервис развернут на третьей площадке и он не зависит от состояния ДЦ где лежат данные.
если вам доступно создание лунов, то кто настраивает репликацию на удаленную площадку и производит переключение репликации после аварии?
ну и наверное есть смысл рассмотреть возможность переноса файлов картинок в БД - блочный доступ более распростанен чем файловый а БД на нем работают быстрее. кстати есть смысл уточнить у хостера оптимальный размер блока на предоставляемом оборудовании, если это нигде явно не указано. особенно если сервис будет проседать на операциях чтения-записи. но по БД я не специалист, как влияет изменение размера блока и доступно ли оно на существующей базе не могу ничего сказать. знаю только что в высоконагруженных СУБД размер блока подбирается под оборудование для максимальной производительности.
Владимир, Вы написали ахинею от начала до конца. мутный бессмысленный поток обрывков знаний из разных областей. Вопрос был про SAN, в ответ Вы рассказываете про MTU и 10Гб на бекэнде. не говоря уже о том, что клиент из своей консоли скорее всего видит (если вообще видит) только виртуальные предоставленные ему устройства и знать не знает ни про каие бонды.
упереться в ограничение iSCSI - плевое дело, и даже Вы сами в своем посте об этом пишите.
ну и превысить лимит дисковых операций сайтом с картинками... мне страшно за Ваших клиентов, из чего вы там хостинг то собрали?
Reinmand Trial, тогда, если хотим сделать хорошо, смотрим на контроллер точек доступа с ВиФи6 (по возможности - чтобы через год-два не пришлось менять все оборудование), а ПоЕ точки доступа ставим на потолок или чердак, соответсвенно пустив провод по чердаку.
если Вас интересует качество выбранного решения - не старайтесь сохранить существующую схему и оборудование, сразу планируйте вариант максимально решающий Ваши задачи. скорее всего все равно придется придти к нему, но это будет длинный и значительно более дорогой путь.
то есть внятного ответа что именно передается через интерфейс во время его максимальной утилизации у Вас нет, Вы даже не задумывались о мониторинге СХД. и это все убеждает Вас в том, что проблема Вами определена правильно. судя по Вашему тону решение ваших проблем вас не интересует, целью было хвастануться каналом в инет и крутой СХД. дерзайте в том же духе ;)
ну и эта, чтобы папка светилась в проводнике ее можно добаввить в быстрый доступ, или подключать диском.
modsamara, вы раздаете не часть. вы раздаете им отдельную подсеть. про маску рассказывать надо?
давайте логически по этапам. удаленный клиент подключается и получает адрес из выделенной подсети которая никак не связана со внутренней сетью. у вас четко просан этот пул:
ip local pool vpn_pool 192.168.201.1-192.168.201.99 mask 255.255.252.0
чтобы клиент увидел внутренню сеть - должен быть маршрут к ней. чтобы ответ из внутренней сети дошел до удаленного клиента изнутри должен быть маршрут к подсети удаленного подключения.
то что Вы в разных местах прописали разные маски не объединяет разные сети, а создает Вам проблемы с маршрутизацией этих сетей. Ваша попытка обхитрить ситему не работет :)
modsamara, у вас две сети - внутрення и для удаленного подключения. между ними нужна маршрутизация в обе стороны. так же не вижу чтобы были прописаны DNS внутреней сети - удаленьщики будут по адресам хоить или по именам?
Талян, L3 для того чтобы за вас все сделал провайдер и Вам не придется тратиться на оборудование и заниматься его настройкой - все филиалы автоматом в одной сети. у нас в городе нет проблем с провайдером - есть такие которые везде присутствуют. а так то они между собой успешно договариваются и арендуют сети друг у друга. л2тп много ресурсов оборудования лопает, хотя если подключений не много то это не так критично. ике2 в этом плане предпочтительнее.
Талян, я так понял, что Вы не знаете как надо сделать чтобы все работало быстро и хорошо. вероятно я ошибаюсь, но тогда Вы задаете странные вопросы :) найдите интегратора с опытом и закажите проект решения. лучше двух чтобы сравнить. писать все здесь долго и лениво :(
так то я бы предложил перевести все на одного оператора связи, по возможности проводного - тогда будет возможность например купить L3 сеть покрывающую все филиалы, или просто шифровать трафик между филиалами (надо считать что выгоднее по стоимости и сколько займет внедрение каждого варианта своими силами). если нужна устойчивость - надо считать требования к RPO и RТO. есть ли смысл покупать резервные каналы и оборудование которое умеет их балансировать и резервировать если у Вас не задублирована серверная часть? надо учесть особенности 1С SQL - для линуха это их собственная сборка, кто будет ее обслуживать? Вы сэкономите на лицензии сервера, но будите платить за более дорогое обслуживание и настройку. ну и тд и тп...
hint000, если бы проблемы пользователей тормозили бизнес - этот вопрос был бы давно решен. если все построено так как построено - значит это выгодно владельцу. иначе он идиот и нет смысла тратить на него время - за больше и лучше работы он все равно не заплатит.
когда я спрашивал это у более опытных товарищей мне сказали что LUN подключить к двум хостам можно, но примаплен он должен быть только на одном. тоесть сделать так можно, сработает, но риск потерять все слишком велик.
разделы, ФС, файлы существуют только на уровне сервера. до СХД по iSCSI доходит только поток блоков данных и команд. что произойдет когда два сервера которые ничего не знают про то что у них общий диск (а LUN они видят как локальное блочное устройство) запишут в него данные - непредказуемо. SCSI - протокол 1978 года стех пор там поменялось только количество подключаемых устройств и добавилась инкапсуляция в IP (iSCSI - SCSI over IP). тогда так подключали локальные диски. тоесть там в принципе не предусмотрена возможность обращения к одному LUN разных хостов.