Комментарии 16
У меня всегда вызывают неприятные ощущения читатели которые минусуют без комментариев. Как то трусовато получается. Вроде подбежал, сделал бяку и спрятался. А в лицо сказать что не нравится — страшно.
Хотите критики? Их есть у меня:
- Ваша статья — не менее чем четвертая на избитую тему:
Каким образом у вас поддерживается климат в серверной?
Измеряем температуру: TEMPer + Python + Windows
Мониторинг температуры гермозоны с помощью 1-wire датчиков и Zabbix 2
- На фотографиях мы видим страшненький монтаж (на который нас просят не обращать внимания). На фоне ставшей уже антиквариатом Cisco 2960 (которая в свое время стоила немалых денег) это выглядит непрезентабельно. Колхозно это выглядит, честно говоря.
- «Программисты» любят информацию складировать и анализировать, а также предоставлять к ней удаленный доступ. Не сидеть же в серверной у дисплейчика все время.
- Внутри коммутатора (и наверняка внутри других железяк в шкафу) тоже есть датчик, но вы его проигнорировали. А ведь это самое интересное — температура внутри железа.
Вот так уже интереснее. Я за нормальный диалог. Отвечаю по пунктам.
1. Это корпоративный блог программы FLProg, и здесь одна из задач поста показать реализацию решений по организации меню, работе с ЕЕPROM, реализацию режима поддержания заданной температуры с помощью программы. Судя по вопросам на форумах посвященных Ардуино, в группах в Контакте, да и на форуме программе многих эти вопросы очень интересуют. Проект для программы выложенный в посту снабжен максимально возможными комментариями.
2.Возможно монтаж и страшненький, но обычно во всех постах посвященных просят более детально показать этапы производства. Ну и плюс хотелось напомнить как раньше изготавливались платы, до эпохи заказного изготовления и ЛУТ. Пробная версия собиралась действительно из того что было, при отсутствии всякой подготовки к изготовлении плат и отсутствии ближе чем в двустах километров цивилизации.
3. Блок управления вынесен в помещение дежурных инженеров(о чем написано в начале статьи), где всегда находится оперативный дежурный. так что в серверной сидеть нет необходимости. В удаленном доступе, как и логировании показаний не вижу смысла. Зачем нужны эти данные? Может это потому что мы все таки не программисты, а инженеры АСУ, и мы не держим лишнюю информацию, и привыкли решать задачи максимально эффективным и экономичным способом.
4. Идеология системы была в автономности и отсутствии зависимости от других железяк. Единственная связь с другим оборудованием — питание от бесперебойника размещенного в шкафу.
1. Это корпоративный блог программы FLProg, и здесь одна из задач поста показать реализацию решений по организации меню, работе с ЕЕPROM, реализацию режима поддержания заданной температуры с помощью программы. Судя по вопросам на форумах посвященных Ардуино, в группах в Контакте, да и на форуме программе многих эти вопросы очень интересуют. Проект для программы выложенный в посту снабжен максимально возможными комментариями.
2.Возможно монтаж и страшненький, но обычно во всех постах посвященных просят более детально показать этапы производства. Ну и плюс хотелось напомнить как раньше изготавливались платы, до эпохи заказного изготовления и ЛУТ. Пробная версия собиралась действительно из того что было, при отсутствии всякой подготовки к изготовлении плат и отсутствии ближе чем в двустах километров цивилизации.
3. Блок управления вынесен в помещение дежурных инженеров(о чем написано в начале статьи), где всегда находится оперативный дежурный. так что в серверной сидеть нет необходимости. В удаленном доступе, как и логировании показаний не вижу смысла. Зачем нужны эти данные? Может это потому что мы все таки не программисты, а инженеры АСУ, и мы не держим лишнюю информацию, и привыкли решать задачи максимально эффективным и экономичным способом.
4. Идеология системы была в автономности и отсутствии зависимости от других железяк. Единственная связь с другим оборудованием — питание от бесперебойника размещенного в шкафу.
Это те статьи — избитая тема. По сути — там простые в реализации но очень сложные и зависимые технические решения(от сети(локальной), от работы промежуточного железа, от операционной системы).
Температура внутри железа не имеет отношения к работе кондиционеров.
Температура внутри железа не имеет отношения к работе кондиционеров.
«Програмиисту» зарезервировать соединения в локальной сети — это написать по одной строчке в конфиге каждого коммутатора, ну и провода дополнительные бросить. То же относится к работе операционной системы — весь экземпляр ОС (тем белее, что он не имеет состояния), можно виртуализировать и поднимать на другом железе в случае отказа или зависания. Это рутинные админские задачи.
В работе кондиционеров очень желательно учитывать состояние и работу железа, чтобы не устраивать в серверной забеги температуры за нагрузкой, а предсказывать и корректировать температуру, удерживая ее всегда на одном уровне.
В работе кондиционеров очень желательно учитывать состояние и работу железа, чтобы не устраивать в серверной забеги температуры за нагрузкой, а предсказывать и корректировать температуру, удерживая ее всегда на одном уровне.
Как я написал в посте, кондиционеры у нас обычные, бытовые. Одного кондиционера всегда хватает. Он поддерживает температуру в серверной около 20 С. Система поддерживает температуру в шкафу между 25 и 27 С. При достижении 27 С включается первая ступень, а при опускании до 25 вентиляция выключается. За три недели температура ни разу не поднялась выше 27С. В случае выхода из строя одного вентилятора при температуре внутри шкафа 30 градусов включится вторая ступень. Ну а что будет при выходе из строя кондиционера и повышении температуры выше 35С я описал ниже, не буду поаторяться
Видел я такую серверную, в которой бытовой кондиционер круглосуточно молотил с уставкой 20 градусов. В итоге стены помещения были вечно холодными, летом на них (снаружи серверной) шло обильное выпадение конденсата и начала развиваться плесень.
Вывод — в серверной не стоит делать «нормальные условия для газовой отрасли» (20 градусов Цельсия и 760мм. ртутного столба). Если в серверной 20 а в шкафах почти тридцать, это симптомчик применения для серверов шкафов с глухими дверцами, предназначенных для коммутации.
UPD: Или применения вместо серверных корпусов с продувом «насквозь» стандартных писюковых кейсов.
Вывод — в серверной не стоит делать «нормальные условия для газовой отрасли» (20 градусов Цельсия и 760мм. ртутного столба). Если в серверной 20 а в шкафах почти тридцать, это симптомчик применения для серверов шкафов с глухими дверцами, предназначенных для коммутации.
UPD: Или применения вместо серверных корпусов с продувом «насквозь» стандартных писюковых кейсов.
Есть и то и другое. Но как говорится что поставили, то и стоит. С тем и приходится работать. Насчет плесени — не переживаем, находимся на крайнем севере, так что стены очень теплые, и конденсат не образуется. Помещение естественно не специализированная серверная, а приспособленное. Шкафы то же какие пришли. Есть сервера и в обычных писюковых корпусах.
А что делать — с тем и живем.
А что делать — с тем и живем.
Совершенно верно. Важнее поддерживать температуру внутри шкафа, а за температуру внутри железа пускай отвечает система терморегуляции серверов. Но в случае выхода из строя кондиционера и превышения температуры внутри шкафа выше аварийной уставки в помещении дежурных инженеров запищит сирена(вообще очень похоже получилось) заморгает подсветка дисплея. Подымет даже спящего (проверенно). Соответственно спасем сервера и диски от перегрева.
Дополнительное замечание по первому пункту.
Сейчас посмотрел Ваши ссылки. Это все системы завязаны на использование сервера( Измеряем температуру: TEMPer + Python + Windows), дорогущей железяки (Каким образом у вас поддерживается климат в серверной? ) которую заказывать и утверждать особая задача, а потом еще год ждать, ну или опять таки сервер (Мониторинг температуры гермозоны с помощью 1-wire датчиков и Zabbix 2).
У нас же получилась небольшая автономная система за смешные деньги (по моему даже 1000 р не набралось) которую можно в принципе безболезненно перенести на любой объект где необходим контроль температуры, и управление вентиляцией или нагревом. Так что отличие все таки есть
Сейчас посмотрел Ваши ссылки. Это все системы завязаны на использование сервера( Измеряем температуру: TEMPer + Python + Windows), дорогущей железяки (Каким образом у вас поддерживается климат в серверной? ) которую заказывать и утверждать особая задача, а потом еще год ждать, ну или опять таки сервер (Мониторинг температуры гермозоны с помощью 1-wire датчиков и Zabbix 2).
У нас же получилась небольшая автономная система за смешные деньги (по моему даже 1000 р не набралось) которую можно в принципе безболезненно перенести на любой объект где необходим контроль температуры, и управление вентиляцией или нагревом. Так что отличие все таки есть
Понимаете, серверная — это место высокой ответственности, и любой незапланированный отказ по вине самопального железа может в итоге обойтись дорого, или даже очень дорого.
Я думаю, организация, позволившая себе купить Cisco за примернно две с половиной тысячи долларов, сможет купить железку за триста баксов, причем в стоечном исполнении, оттестированную на электромагнитную совместимость и с гарантией…
Я думаю, организация, позволившая себе купить Cisco за примернно две с половиной тысячи долларов, сможет купить железку за триста баксов, причем в стоечном исполнении, оттестированную на электромагнитную совместимость и с гарантией…
Да конечно, наша организация может себе позволить купить практически любую железяку. Но только пока заявка пройдет все инстанции про эту железяку, придет к нам, пройдет где-то год. Да и зачем ставить что то сложное. У нас все равно проводится регулярный обход помещений, а эта система только способ скорее отреагировать на выход из строя кондиционера, и перейти на резервный. И мне автономная вынесенная система кажется более надежной чем встроенная в стойку вместе со всем остальным оборудованием. В любом случае доверять ей начнем только после нескольких месяцев безотказной работы.
Я бы все-таки проработал вопрос помехоустойчивости. То что вы развели силовые цепи и сигнальные это всего лишь сокрытие проблемы а не её решение. Провода длиннее 30 сантиметров уже нуждаются в мерах защиты от ЭМИ. Сейчас не зависает, а начнется статика или какие-то работы по соседству и будет снова виснуть. Там бы в контроллере вач-дог использовать и т.п.
На следующую вахту из офиса привезут экранированную сетевуху. Я думаю это решит проблему окончательно. Для начала попробую кинуть концы раза в два — три длиннее чем нужно. У меня будет месяц на тестирование и эксперименты, там и выяснится. Насчет вач-дог-а я подумаю. Он пока не реализован в FLProg, подумаю над реализацией.
Руководство отдела, зная о моей работе над проектом FLProg, предложило создать систему мониторинга температуры в серверных шкафах
Было бы лучше, если бы руководство предложило купить оборудование климатического контроля шкафов.
Да это было бы конечно лучше. Но Вы же знаете как это происходит. В конце года делается заказ на следующий год, потом в конторе половина выкидывается, потом тендер на поставку, и к концу следующего года может быть придет. Да и менеджерам в офисе необходимо еще доказать необходимость этого оборудования. Процентов на 90 ответ будет такой «У вас же регулярные обходы, не нужно вам этого». Не раз такое уже было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контроль температуры в серверных шкафах с помощью Ардуино