Конкретные цифры очень сильно зависят от конкретной конфигурации массива. Кроме того IOPS это параметр, сильно подверженный влиянию случайных факторов.
Поэтому гарантировать минимум для него — так же нереально, как, к примеру, гарантировать минимум скорости передвижения автомобиля по городу.
Но это ничуть не мешает сделать SLA по статистическим показателям, например среднее значение за минуту с нормированным среднеквадратичным отклонением.
Правда есть еще такой фактор, как аварийные ситуации. Вам придется либо закладываться на нужную производительность, даже в случае ребилда массива, либо обговаривать их отдельно.
Гарантировать производительность могут не производители полок, а производители дисков :)
А от стораджа и его конфигурации уже будет зависеть, какой процент этой производительности вы тратите на отказоустойчивость, на бекапы и т.д.
Рассчитать пусть не минимальные гарантии, но статистическое среднее/стандартное отклонение можно довольно просто.
Жидкостное охлаждение на проц с фреоном или другой жидкостью с подходящей температурой кипения, может быть источником пара :) Экономия аж нескольких ватт электроэнергии :)
Шестеренки могут быть механическим приводом всех кулеров или помпы от одного двигателя.
С системой понижения/повышения передач на переключателях или сервомоторах для регулировки скоростей.
Подтверждаю, PBR + NAT на 2х 10мбит каналах грузил 1840 на 30-40 cpu при полной нагрузке обоих каналов. С ip cef вероятно будет еще меньше, но там могут быть неприятные побочные эффекты
А почему не OER для балансировки исходящих соединений?
По поводу обратного маршрута — что скажете насчет такого варианта:
прокинуть inside static NAT (PAT);
Настроить dynamic NAT на основе route-mapов на оба маршрута
с включенным ip cef входящее соединение кеширует маршрут и ответный пакет попадает на нужный интерфейс, где NAT-ится с нужным адресом.
К сожалению не нашел нужного конфига в своих архивах, чтобы показать пример.
Ничего ужасного в этом нет, у меня на прошлом месте работы стоял проф. спутниковый приемник для кодированного сигнала за X килобаксов, который работал на проце… Z80 :)
В нем, как и в цисковских железках CPU нужен для работы операционки, а коммутация, маршрутизация, шифрование, и т.п. выполняются непосредственно железом/его прошивкой.
P IV 2800 вполне достаточно, чтобы обслуживать красивые графики в ASDM
Серверные корпуса для установки в стойку шумят очень некисло, слышно будет даже через стену / две стены
Башни супермикро есть и тихие вроде, но это надо смотреть по конкретной модели…
ATX-мамки не факт, что подойдут далеко не во все рековые корпуса. В 2U карточка полной высоты влезает только с riser card, т.е. ее должна поддерживать мамка.
ключевой вопрос в системе отсчета…
быстрее относительно чего? и медленнее относительно чего?
Стороны земли движутся с одинаковой (нулевой) скоростью относительно друг друга. Соответственно разницы в течении времени нет.
Вот часы расположенные на солнце будут идти почти незаметно быстрее для дневной стороны и медленнее для ночной.
Ага, одна из основных причин RAID — это повышения количества IOPS на одном разделе. Как никогда актуально для СУБД и почты. А сохранность данных должен обеспечивать бекап, а не массив.
+1 Волосы на голове дыбом от таких выкладок. Даже если не учитывать спорность исходных посылок.
А о них хотелось бы сказать:
НЕЛЬЗЯ считать выход из строя дисков в массиве независимыми событиями.
Выход из строя 1 диска сразу дает большую нагрузку на остальные.
При расчете вероятности выхода из строя 2-го и последующих дисков нужно учитывать время, которое массив проводит в degraded режиме. Если вы вовремя будете заменять диски, или держать hot spare — это намного понижает вероятность сбоя, чем если вы узнаете о сбое первого диска только после второго сбоя и мертвого массива.
Поэтому гарантировать минимум для него — так же нереально, как, к примеру, гарантировать минимум скорости передвижения автомобиля по городу.
Но это ничуть не мешает сделать SLA по статистическим показателям, например среднее значение за минуту с нормированным среднеквадратичным отклонением.
Правда есть еще такой фактор, как аварийные ситуации. Вам придется либо закладываться на нужную производительность, даже в случае ребилда массива, либо обговаривать их отдельно.
А от стораджа и его конфигурации уже будет зависеть, какой процент этой производительности вы тратите на отказоустойчивость, на бекапы и т.д.
Рассчитать пусть не минимальные гарантии, но статистическое среднее/стандартное отклонение можно довольно просто.
С системой понижения/повышения передач на переключателях или сервомоторах для регулировки скоростей.
По поводу обратного маршрута — что скажете насчет такого варианта:
прокинуть inside static NAT (PAT);
Настроить dynamic NAT на основе route-mapов на оба маршрута
с включенным ip cef входящее соединение кеширует маршрут и ответный пакет попадает на нужный интерфейс, где NAT-ится с нужным адресом.
К сожалению не нашел нужного конфига в своих архивах, чтобы показать пример.
В нем, как и в цисковских железках CPU нужен для работы операционки, а коммутация, маршрутизация, шифрование, и т.п. выполняются непосредственно железом/его прошивкой.
P IV 2800 вполне достаточно, чтобы обслуживать красивые графики в ASDM
Башни супермикро есть и тихие вроде, но это надо смотреть по конкретной модели…
ATX-мамки не факт, что подойдут далеко не во все рековые корпуса. В 2U карточка полной высоты влезает только с riser card, т.е. ее должна поддерживать мамка.
быстрее относительно чего? и медленнее относительно чего?
Стороны земли движутся с одинаковой (нулевой) скоростью относительно друг друга. Соответственно разницы в течении времени нет.
Вот часы расположенные на солнце будут идти почти незаметно быстрее для дневной стороны и медленнее для ночной.
А о них хотелось бы сказать:
НЕЛЬЗЯ считать выход из строя дисков в массиве независимыми событиями.
Выход из строя 1 диска сразу дает большую нагрузку на остальные.
При расчете вероятности выхода из строя 2-го и последующих дисков нужно учитывать время, которое массив проводит в degraded режиме. Если вы вовремя будете заменять диски, или держать hot spare — это намного понижает вероятность сбоя, чем если вы узнаете о сбое первого диска только после второго сбоя и мертвого массива.