Правильный подход - это всегда понятие растяжимое..
С точки зрения продавца, правильно сделать кластер, автоматическую балансировка итд. И продать лицензий на круглую сумму.
Неправильно - купить продукт и не использовать.
Если у Вас есть живая миграция, значит для кластера есть все необходимое.
Даже в кластере, для VM можно указать на каких узлах она может запускаться.
Без кластера, сама по себе машина никуда мигрировать не может.
Выписываем возможные неисправности:
- умер хост
- умер массив целиком
Продумываете что будете делать в каждом случае. За сколько времени поднимете.
Принимаете решение - устраивает или нет..
С общим томом потенциальные особенности:
Легче развести бардак. (а чьи это данные, от какой VM, какого хоста)
При перестановке хоста легче убить все данные. (был случай, переставляли ОС на хосте, и поставились на общий том.
Отсюда правило - при перестановке, внешние хранилища должны быть отключены)
При использовании отдельных томов, растёт фрагментация (в сумме - место есть, а единого - нет)
При отдельных томах можно на массиве задать им QoS, при этом отдельные тома могут быть все равно общими.
Нет общих правил. Есть задачи..
Может Вам надо раздать хосты разным администраторам, и надо что бы они не видели чужие данные...
Модель raid контроллера, модель дискового бэкплейна (или хотя бы он активный или с sas-expander)
Сколько и каких кабелей идёт от контроллера до дисков/ бэкплейна.
Если диски sas, используется один порт или два.
Модель дисков.
С какими сообщениями отваливаются диски.
Дмитрий Береза,
Каждый адрес, порт настраивается индивидуально. Можно было где-то опечататься. Чего гадать?
Надо смотреть что приходит и уходит...
tcpdump в руки..
Дмитрий Береза,
Тогда tcpdump на Ubuntu, смотреть и думать.
И да, проверять надо из другой сети. (с мобильного, например)
С соседнего ПК может не работать...
Я не знаю как в Cisco, но обычно, в таблице маршрутизации обязательно указывается router, через который надо отослать запрос.
То-есть стандартный алгоритм такой:
Если адрес назначения укладывается в текущую подсеть, то используется arp для поиска Mac-адреса.
Если по сеть чужая, ищем мак-адрес роутера сети назначения.
В качестве теста можно попробовать добавить руками arp запись для 192.168.2.2 и посмотреть что будет.
Я не знаю, насколько софт эмуляция корректно работает на таких граничных задачах.. Может на физике поведение будет отличаться...
Вадим, ну так сделайте, что бы имя хоста отличались или путь (prefix) в URL.
Грубо:
company.ru проверяет, есть ли авторизация и если нет, то отправляет на
company.ru/login
Балансировщик знает, что если впереди есть /login, то ножа отправлять на контейнер авторизации.
Контейнеры же приложение) обслуживают не одного пользователя, а кучу. То-есть кто-то прошёл авторизацию, а кто-то ещё нет.. Поэтому на уровне контейнеров эту проблему не решить. Это уровень приложения.
Вы давайте пользователю токен авторизации (cookie). И бэкеннд будет знать: есть авторизация - работаем. Нет - редиректим на страницу авторизации.
Если разные сайты (докеры) отвечают за разные части по URL запроса, то перед ними ставят балансровщик (reverse-proxy). Тот же nginx, который исходя из URL запроса сам дальше переводит на один сайтов (хоть по портам могут отличаться, хоть по адресам).
С точки зрения продавца, правильно сделать кластер, автоматическую балансировка итд. И продать лицензий на круглую сумму.
Неправильно - купить продукт и не использовать.
Если у Вас есть живая миграция, значит для кластера есть все необходимое.
Даже в кластере, для VM можно указать на каких узлах она может запускаться.
Без кластера, сама по себе машина никуда мигрировать не может.
Выписываем возможные неисправности:
- умер хост
- умер массив целиком
Продумываете что будете делать в каждом случае. За сколько времени поднимете.
Принимаете решение - устраивает или нет..
С общим томом потенциальные особенности:
Легче развести бардак. (а чьи это данные, от какой VM, какого хоста)
При перестановке хоста легче убить все данные. (был случай, переставляли ОС на хосте, и поставились на общий том.
Отсюда правило - при перестановке, внешние хранилища должны быть отключены)
При использовании отдельных томов, растёт фрагментация (в сумме - место есть, а единого - нет)
При отдельных томах можно на массиве задать им QoS, при этом отдельные тома могут быть все равно общими.
Нет общих правил. Есть задачи..
Может Вам надо раздать хосты разным администраторам, и надо что бы они не видели чужие данные...