да чо вы к проксе прицепились? это типовое название ошибки в хроме - к проксе вообще никакого отношения не имеет, он всегда так пишет когда подключиться не может. как дети, будто впервые прочитали полностью название ошибки...
и что, пользователи постоянно генерят столько данных, что вот это все дает заметное улучшение производительности? а то я что-то смутно припоминаю что и при апдейте СУБД обрабатывает все поля записи и вробе бы отрезать пустой ввод можно тригерами...
192.168.100.0/16 - адрес сети, а не хоста. по адресу 192.168.100.0 хоста просто не может быть - адрес сети невозможно назначить устройству. во всяком случае на физическом устройстве это не должно получиться.
по RFC сети 192.168.0.0 должны иметь не более 254 хостов. корректная работа сети 192.168.100.0/16 не гаранирована. если Вам нужны подсети из более 254 хостов - используйте сети в диапазонах 172.х.х.х или 10.х.х.х
кстати не задумывались - почему хостов на 2 меньше чем адресов в сети? ;)
получается в воркстейшен отслеживание корректности сетевых настроек для ВМ вообще не реализовано.
Kwad, модемы ведь имеют адрес на этом ПК? настраивайте впн для них, а не для модемов. или я опять не правильно понял :(
опять же, раньше ведь провайдеры успешно по этой схеме работали. вот только сомневаюсь что на винде. значит решение есть.
либо разделить роли - модемы получили IP адреса и впн настраивать уже для этих адресов, а не напрямую модемам.
так Вы хотите на 7ке поднять ВПН? и у вас там реально 20 сетевушек? пока что задача выглядит фантастичной - достаточно двух сетевушек, 7ка далеко не самых лучший выбор.
grabbee, это значит репликацию (резервироание) на удаленную площадку кто-то настроит. при репликации задается исходное СХД и целевое (резервное). репликация работает всегда в одну сторону. на целевой лун, если репликация не актив-актив, запись недоступна. у вендоров обычно есть софт который автоматически отслеживает доступность площадок и при падении основной переключает целевую в исходную делая доступной запись. ну или это делается вручную. после этого возможно переключение сервиса на работу с резервным ДЦ. при восстановлении основной площадки репликация включается в обратную сторону. когда она завершится для возврата на первую плозадку (если это нужно, например для резервирования часто используют менее производительное оборудование для экономии, не факт что в вашем случае это так, у хостера оба ДЦ могут быть одинаковыми) надо остановить сервис, остановить репликацию, переподключить сервис на первую площадку, поменять направление репликации и включить ее после этого запустить сервис. (звучит муторно, но я писал это дольше чем это делать) если репликация актив-актив то переключение между площадками возможно в любой момент.
тоесть если у вас резервирование актив-актив вы можете сами в любое время переключаться между площадками (если сервис сам не умеет НА процедура всегда одна - остановить сервис, отмапить, примапить, включить сервис). а если синхронное или асинхронное - вам при переключении нужно согласовывать это с хостером чтобы сохранить консистентность данных.
если сервис лежит там же где данные и падает вместе с ними при аварии - все немного проще. когда все упало и хостер подтвердил аварию и необходимость перехода на резервную площадку - запускаете сервис на ней. если надо вернуться на первую - при актив-актив просто гасите сервис на резервной и запускате на основной, в другом случае уточняете у хостера нужно ли согласовывать это с ним для корректного резервирования.
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 (по возможности - чтобы через год-два не пришлось менять все оборудование), а ПоЕ точки доступа ставим на потолок или чердак, соответсвенно пустив провод по чердаку.
если Вас интересует качество выбранного решения - не старайтесь сохранить существующую схему и оборудование, сразу планируйте вариант максимально решающий Ваши задачи. скорее всего все равно придется придти к нему, но это будет длинный и значительно более дорогой путь.
то есть внятного ответа что именно передается через интерфейс во время его максимальной утилизации у Вас нет, Вы даже не задумывались о мониторинге СХД. и это все убеждает Вас в том, что проблема Вами определена правильно. судя по Вашему тону решение ваших проблем вас не интересует, целью было хвастануться каналом в инет и крутой СХД. дерзайте в том же духе ;)
ну и эта, чтобы папка светилась в проводнике ее можно добаввить в быстрый доступ, или подключать диском.
