Хорошая идея. Жалко, что нет легкого способа тримить только ненужные участки, а только диск или раздел целиком. Но и это уже дает ощутимую пользу.
Чтобы не пострадала отказоустойчивость, перед тримом можно в массив добавить третий диск в качестве активного участника и вынимать диск для чистки только когда синхронизируется третий диск.
cvss добавил 23.11.2011 в 21:31
У нас в поддержке мысли читать научились - я еще даже не выяснил, кто темп потерял, а уже все поняли и исправили :)
Harius, вышлите, пожалуйста, мне в личку номера неотвеченных тикетов. Я проведу с молчануми мотивирующие беседы :). Надеюсь, у этого будет недискредитирующее объяснение.
А у задержек с ответами с конца прошлой недели есть позитивное причина. Устанавливаем, тестируем партию нового мощного оборудования - работы на всех навалилось больше, чем обычно.
На необходимость прокладывать СКС в ДЦ зачем-то вы настаиваете. Как я уже говорил, в этом необходимости нет (под СКС я понимаю классическое определение, см. например, википедию).
Vanger все правильно пишет. Соединение оборудования внутри стойки вообще никаким образом с СКС не связано, никакой сложности ни для кого не представляет. Кабели между стойками и в комнату связи тоже могут быть либо проложены своими монтажниками, либо заказаны у инженерной службы ДЦ - в зависимости от политики ДЦ в этом отношении или от целесообразности использования своих или чужих монтажников. Тоже никакой сложности.
Со своими стойками (имею в виду рамы для крепления 19" оборудования ) в чужих ДЦ - да, соглашусь что я выразился недостаточно ясно и меня можно было истолковать так, что и их мы привозим свои. Тут однозначно скажу, что нет, пока еще ни в одном постороннем ДЦ свои стойки (в смысле, рамы) мы не привозили, т.к. нас устраивают те стойки, который предоставляют ДЦ. Хотя и такой вариант не должен вас удивлять - если стандартное предложение заказчику не подходит, то многие ДЦ предлагают заказчику ставить его стойку. Главное, чтобы она соответствовала техническим требованиям размещения - по габаритам, весу и т.д. Например, в одном месте, рядом с нами стоит закрытый шкаф комстара, который они сами привезли, собрали, заполнили. Им понадобилось - ДЦ с удовольствием дает условия. Нам достаточно того, что есть - стоим в общей стойке.
Прокладывать оптику в ДЦ - если есть рядом своя точка присутствия и стоимость прокладки будет меньше стоимости аренды волокна или влана, разумеется, выгоднее проложить.
А почему все это для вас звучит фантастически?
Как вам будет угодно, я же не в "верю-не верю" с вами играю :)
В машинных залах СКС не нужна, у нее другое назначение. СКС в ДЦ может быть разве что в административной части здания и у охраны. А для коммутацию своего оборудования, размещенного в стойках, удобнее использовать собственные пассивные и активные компоненты.
Дата-центры бывают разные, и услуги у них можно брать разные. Если брать "все под ключ" - питание, охлаждение, внешнюю связность, локальную сеть, сетевое оборудование, серверы, сервисных инженеров - тогда, ясное дело, от ДЦ зависит очень многое.
У нас из всего этого в чужих датацентрах берется только питание и охлаждение, хотя даже бывает и UPS свои ставим. По опыту, из всех причин недоступности веб-сайтов, происходящих в зоне ответственности провайдера, на долю проблем с электроснабжением или охлаждением сервера приходится около 5-10%. Все остальное приходится на выход из строя оборудования, сбои в работе ПО, недостатки в организации системы, человеческий фактор и еще десятки других причин. Это та часть, которую мы контроллируем, вкладываем в нее свой опыт, исследования и разработки, и берем на себя за нее ответственность.
По поводу каналов связи в ДЦ - cеть у нас своя (AS48235). К ДЦ можно либо свою оптику дотянуть, либо соединиться по купленной или арендуемой чужой оптике.
На одинаковом оборудовании 64битный LAMP (Drupal) работает примерно на 5% быстрее, чем 32битный (если не тормозится диском или сетью). Выигрышь, в первую очередь, на вычислительных, CPU-intensive задачах за счет большего числа регистров процессора в 64битном режиме и связанных с этим больших возможностей по оптимизации кода компилятором.
Если с ресурсами все плохо, то периоды с сильным выходом за границы нормы бывают десятками минут. В таком случае, минутное усреднение их не скроет и они будут видны.
Но если ресурсов, в целом хватает, но уже на грани, минутные интервалы это сгладят. Вместо резких пиков будет видно небольшое повышение. И постфактум будет трудно понять, было ли это общее повышение посещаемости без возникновения больших задержек, или это были уже серьезные проседания. Просто придется смотреть в эти периоды намного больше информации - не появляются ли в этот момент какие-то ошибки в логах apache, mysql, ядра.
Для веб-сайтов интервала в 1 секунду хватает вполне. Для IP-телефонии или вещания, вероятно, был бы полезен более короткий интервал, но в этих случаях достаточность ресурсов удобнее проверять по времени выполнения запросов, получаемом от самого серверерного приложения.
О прошлом такую статистику уже не извлечь, показывается только текущую, и можно сохранять вывод в лог. vmstat 1 - будет выводить использование за каждую секунду. Запустить командой nohup vmstat 1 > vmstat.log & - и пару дней покопить в лог. Потом либо руками/утилитами в консоли, либо в какой-нибудь excel и там отсортировать, сделать статистический анализ, можно графики построить посмотреть.
Можно сделать интервал больше, например, vmstat 3600 за час, но из-за усреднения он будет уже не очень информативен, т.к. пиковые моменты, обычно, бывают короткими, и при таком усреднении просто станут невидны.
Для красивых графиком - можно munin и прочее. Они, с одной стороны, проще - установил один раз и потом периодически смотришь графики. Но мне, например, удобнее vmstat - более информативно и при необходимости можно сложные случаи распутывать.
