Стандартные тупые свитчи в паре на каждый Rack + два менее тупых 10G L3 свитч в стойке с серверами баз данных.
И первое и второй можно не Cisco. А можно и Cisco. И все будет работать и 5 девяток.
В нормальных датацентрах дают обычно 2 шнурка для Интернета. А если попросить — то хоть еще 10-ть (часто за отдельную плату).
Я, честно говоря, не могу вспомнить чтобы у меня или у моих клиентов Cisco сам «грохался».
Но я точно знаю что пять девяток надежности это 5 с половиной минут в год простоя. Готовы такое обеспечить на одном свитче? Я бы не стал на такое соглашаться. А если срочное обновление, а если вентилятор внутри перестал вращаться? и т.д. и т.п.
К тому же, если Security update — то будете ждать нового года чтобы прошивку перезалить?
1. Дайте количество серверов, которые планируете подключать. Отдельно напишите сколько серверов собираетесь подключать по 1G, сколько по 10G. Сервера с 10G в одной стойке стоять будут? Или хаотично, с учетом роста серверной фермы?
2. Будете сложный firewall наворачивать, или NAT? Нужен какой-то учет трафика кто куда ходил?
3. Текущий хостер отвечает что ПО на ваших серверах поднимет 20G агрегированный линк и железо на вашем сервере прокачает 20Gbit/s данных через свои шины и через указанные сетевые карты?
4. — 5. Если вам не нужно разделять сервера firewall-ом (или в будущем как-то делить их), то все можно загнать в один vlan. Если же тревожно и хочется web frontend-ы от web backend-ов отделить — то можно загнать в разные vlan. Благо что маршрутизария на wirespeed работает на L3 свитчах.
6. Почитайте вот тут дизайнерский документ от Cisco как следуюет делать датацентры. www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/nx_7000_dc.html www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VMDC/2.2/design_guide/vmdcDesign22.html
Там не на все следует обращать внимание, но чтобы понимать о чем всё это — советую почитать.
А остальные ресурсы — это в гугл идти и спрашивать — нет единого места — есть кучка блогов где про это пишут.
4. Вопрос в том, нужно ли делать отдельную физическую сеть для управления IPMI карточками серверов.
Суть вопроса, как я понимаю, даже если основная сеть перегружена — мы не потеряем управления над серверами.
\n Matches what the nth marked subexpression matched, where n is a digit from 1 to 9. This construct is vaguely defined in the POSIX.2 standard. Some tools allow referencing more than nine capturing groups.
1. Смотрите на флаг fin. Если он = 0, то ждите еще данных
2. При получении пакета смотрите на его sequence number. Если это число больше, чем sequence number предыдущего пакета + длина предыдущего tcp пакета (обязательно посмотрите в RFC как происходит приращение sequence number — потому как я могу быть не прав) — то пропущен пакет — пакеты — нужно ждать их и не использовать текущий пакет. А если полученный sequence number такой, какой вы ожидали — пакеты не пропущены.
Делайте буфер. Принимайте пакет 2, ждите, когда придет недостающий пакет, добивайте им буфер и отправляйте на уровень выше. Вообще, я бы не советовал делать в своем приложении реализацию tcp стека. Может быть эту задачу можно реализовать как-то по-другому?
Вооот. Делаете такой же дебаг на рабочей cisco, смотрите что там пишет. Смотрите что «плохая» cisco думает про лицензии.
И вообще, как Дима посоветовал — ищите разницу между хорошей и плохой. Берите в руки какой нибудь визуальный diff, python/perl чтобы в дебагах постирать всякое там время и смотрите
Но вообще, когда Cisco перестает шифровать по Easy VPN и SSL VPN на ней так же не работает (я прав?), то я бы эту Cisco из эксплуатации выводил.
