Сколько NICs на блейд Вы имеете? Надлежащее решение iSCSI потребует 4.
2 должен пойти для связывания интерфейсов (вероятно, в режиме 1), таким образом, можно потерять nic (или переключатель (или кабель)), не теряя возможность соединения.
Другие 2 должны быть установкой с многопутевым к цели iscsi, и они должны быть в их собственной сети с их собственными переключателями. iSCSI/can/направляться и рассматриваться как нормальный сетевой трафик, но по словам всех людей я говорил, это/shouldn't/быть.
Уровень фактического трафика на сайт не важен.
Все те настройки (за исключением "TTL по умолчанию") только влияют, как часто вторичные серверы DNS Вашего домена опрашивают основной сервер DNS относительно обновлений.
Если Ваша зона только нечасто изменяется (который я полагаю, что Ваша делает), затем, Ваше значение для "обновления" находится в настоящее время немного на низкой стороне. Обычно основное устройство должно отправить a NOTIFY
обменивайтесь сообщениями к каждому из вторичных устройств каждый раз, когда существует обновление, при которой точке вторичные устройства сразу захватывают зональный файл. В эти дни "обновление / повторная попытка / истекает" механизм, только поддержка к этому.
В любом случае вероятно, что Ваш поставщик DNS автоматически синхронизирует изменения во всех соответствующих серверах DNS на лету, не используя встроенные механизмы синхронизации DNS, таким образом, фактические значения, вероятно, не важны.
Обратите внимание, что "TTL по умолчанию" поле больше не означает то, что это говорит. Реальный TTL по умолчанию установлен (в BIND, по крайней мере) с $TTL
директива, и это только используется, когда нет явного набора TTL на каждой записи.
"TTL по умолчанию" значение поля был изменен в RFC 2308, и это - на самом деле подсказка для отрицательного кэширования. Если Ваш сервер возвращает отрицательный ответ (например. NXDOMAIN
или NODATA
) это - сколько времени удаленный сервер должен ожидать перед тем, чтобы попробовать еще раз.
Текущее значение находится немного на низкой стороне, но нет никакого вреда, оставляя его, как. Это часто игнорируется так или иначе.
Интересно, страница диагностики DNS от dyn парней (наши хосты DNS)..
http://dnscog.com/report/stackoverflow.com
.. говорит это относительно MINTTL:
Проверьте SOA MINTTL
Ваш SOA minttl значение составляет 60 секунд, который ниже, чем рекомендуемый минимум для общего использования DNS. Если Вы регулярно вносите изменения в свою зону DNS или используете основанные на DNS услуги по выравниванию нагрузки, маленькое значение здесь в порядке.
Рекомендация
Рассмотрите значение помещения между 1800 и 86400 к Вашему SOA minttl поле.
и это на обновлении SOA
Проверьте обновление SOA
Ваше поле обновления SOA составляет 3 600 секунд, который ниже, чем рекомендуемый минимум. Наличие низкого значения обновления может привести к ненужному объему запроса или неожиданному поведению, особенно при использовании значения 0. Если Вы регулярно будете вносить изменения в свою зону DNS или будете использовать основанные на DNS услуги по выравниванию нагрузки, то меньшее значение поможет гарантировать, чтобы изменения распространили как можно быстрее.
Рекомендация
Рассмотрите значение помещения между 7 200 и 10800 к Вашему полю обновления SOA.
Другая диагностическая страница по http://www.intodns.com/stackoverflow.com не предлагает реальных подсказок.
Из Пинсайда: http://dnscheck.pingdom. com/
SOA TTL recommended >= 3600.
SOA refresh recommended >= 14400.
SOA retry recommended >= 3600.
SOA expire recommended >= 604800.
SOA minimum recommended between 300 and 86400.