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, если бы проблемы пользователей тормозили бизнес - этот вопрос был бы давно решен. если все построено так как построено - значит это выгодно владельцу. иначе он идиот и нет смысла тратить на него время - за больше и лучше работы он все равно не заплатит.
я правильно понял что Вы не понимаете что делали и с какой целью? если не секрет - зачем? зачем потрачена куча времени на то чтобы все это установить, отрыть, наделать скринов? попробуйте решать задачу, а не плодить новые - просто загуглите "svhost грузит"
jollygulf, по поводу хабов, коммутаторов и маршрутизаторов у Вас большая путаница. все не совсем так как Вы пишите, все и проще и сложнее. и к Вашему вопросу вообще отношения не имеет. да и начинать изучение надо совсем с другого...
если вам доступно создание лунов, то кто настраивает репликацию на удаленную площадку и производит переключение репликации после аварии?
ну и наверное есть смысл рассмотреть возможность переноса файлов картинок в БД - блочный доступ более распростанен чем файловый а БД на нем работают быстрее. кстати есть смысл уточнить у хостера оптимальный размер блока на предоставляемом оборудовании, если это нигде явно не указано. особенно если сервис будет проседать на операциях чтения-записи. но по БД я не специалист, как влияет изменение размера блока и доступно ли оно на существующей базе не могу ничего сказать. знаю только что в высоконагруженных СУБД размер блока подбирается под оборудование для максимальной производительности.