https://opennet.dev/openforum/vsluhforumID3/50681.html Экономический спад способен ускорить процесс внедрения Linux компаниями различного уровня. К таким выводам подводят результаты опроса (http://www.informationweek.com/news/software/linux/showArticle.jhtml?articleID=215900055) среди ответственных лиц IT департаментов, который, по заказу Novell, проводила компания IDC. Больше половины респондентов из Европы, Америки и Азии заявили, что уже используют в своем бизнесе Linux серверы и планируют расширять сферу их применения.<br><br>В опросе приняло участие 330 представителей компаний, 65% из которых намереваются к концу года увеличить как минимум на 10% объем использования Linux в своем серверном парке. 63% имеют аналогичные планы в отношении использования Linux десктопов. 49% ожидают, что Linux перейдет в разряд основной серверной платформой. Случайность или нет, но число респондентов (62%), заявивших, что их IT бюджет значительно урезан, и заставляет их действовать более осмотрительно, очень близко коррелирует с уже упоминавшимися выше планов...<br><br>URL: http://www.inf https://opennet.dev/openforum/vsluhforumID3/50681.html#49 Mon, 23 Mar 2009 11:49:37 GMT Сразу видно - человек не знает о чем говорит.<br><br> https://opennet.dev/openforum/vsluhforumID3/50681.html#48 Mon, 23 Mar 2009 08:20:51 GMT &gt;&gt;Да хоть джента. Без мониторинга железа на серверах и критичных рабочих станциях <br>&gt;&gt;линуксу не место. Желающие искать приключений с "внезапной" потерей данных - <br>&gt;&gt;могут использовать. <br>&gt;<br>&gt;Ой-ой-ой. На практике это трата ста баксов, чтоб избежать риска на десять <br>&gt;центов. Весь этот мониторинг железа. Да и кто вам сказал, что <br>&gt;тот же нагиос не справиться с мониторингом чего угодно? Были преценденты? <br>&gt;У меня нет. Вся инфраструктура, бэкап и биллинг на линуксе. <br><br>Вы обработку отказов ОБОРУДОВАНИЯ проверяли? Если нет - говорить не о чем.<br>Если да - поделитесь опытом как через нагиос мониторить raid, кулера, датчики всякие.<br>Буду благодарен.<br><br>а про 10 центов вы будет начальнику объяснять когда raid сдохнет "внезапно"... Не завидую.<br> https://opennet.dev/openforum/vsluhforumID3/50681.html#47 Mon, 23 Mar 2009 08:10:17 GMT &gt;&gt;Да хоть джента. Без мониторинга железа на серверах и критичных рабочих станциях <br>&gt;&gt;линуксу не место. Желающие искать приключений с "внезапной" потерей данных - <br>&gt;&gt;могут использовать. <br>&gt;<br>&gt;Ой-ой-ой. На практике это трата ста баксов, чтоб избежать риска на десять <br>&gt;центов. Весь этот мониторинг железа. Да и кто вам сказал, что <br>&gt;тот же нагиос не справиться с мониторингом чего угодно? Были преценденты? <br>&gt;У меня нет. Вся инфраструктура, бэкап и биллинг на линуксе. <br><br>Ну да получить уведомление типа "сервер не пингуется" это одно, raid degraded это другое, raid failed это третье, а кулер помер и корзина с дисками сгорела это четвертое. Нагиос решает только первое. Прочувсвуйте разницу.<br><br>Вы обработку отказов оборудования проверяли до постановки его в продакшн? Если нет - то дальше говорить просто не о чем.<br><br> https://opennet.dev/openforum/vsluhforumID3/50681.html#46 Mon, 23 Mar 2009 07:56:09 GMT &gt;Чистой воды брехня. Вы, батенька, Вин-бот. Это довольно тривиальная задача и решается <br>&gt;она без всяких сложностей. Это, конечно, не умаляет возможностей платных решений. <br>&gt;Но если они по какой-то причине недоступны, почему бы и самому <br>&gt;не сделать? <br><br>Чистой воды голый апломб, батенька, без аргументации. Вы батенька, лин-бот. :) (высокий уровень дискуссий, ничего не скажешь)<br><br>"Это довольно тривиальная задача " - вы про какую задачу?<br><br>Вот вам задачка. Сервер. MB Intel SE7501BR2S RAID SRCU32 + SRCU42X. Прошу дать хотя бы ссылки на софт для мониторинга и управления этого оборудования в современном дистрибутиве линукса/юникса. Опробованы - SUSE 10 (Open, Ent Serv, Ent Desktop, Debian 4, Debian 5, FreeBSD 6.4, 7.0, 7.1. Сейчас работает FreeBSD 7.1, ПО неполного мониторинга и управления RAID устанавливалось с чудесами и доделками руками, часть проблем остались нерешенными, но т.к. аппарат работает тестовым полигоном, то не критично.<br><br> Для виндов все решение обойдется ~1200$ и 1,5 часа времени. Вот соотнес https://opennet.dev/openforum/vsluhforumID3/50681.html#45 Mon, 23 Mar 2009 07:24:42 GMT &gt;&gt; Аналогично с FreeBSD/FreeNAS. Да решение дешевое с виду... <br>&gt;<br>&gt;А у MS даже с виду - не дешевое.Сразу хотят вагон бабла <br>&gt;за софт, OS, ... .И потом еще постоянная дойка на клиентские <br>&gt;лицензии.Если подходить с умом - на линухе можно нехило экономить.А если <br>&gt;по ламерски и без знания вопроса - ну, "сдуру можно и <br>&gt;х.. сломать" ;) <br><br>Если подходить с умом - то линукс в продакшн ставить можно только для очень узкой сферы задач. Для широкого бизнес-применения он просто не полходит, и корень проблемы - в отсутствии единых стандартов. Анархия в API, одна только несовместимость приложений для разных диструбивов чего стоит. Максимально готовый к бизнес-применению в SMB-сетях мною дистрибутив - SUSE Enterprize Desktop. Прочие требовали значительных доработок элементарнейших вещей с соотв. потерями времени (невосполнимый ресурс)<br><br> Предположим у вас идеальный случай - полностью однотипное и полностью совместимое с неким дистрибутивом оборудование. Стадия запуска прошла успешно, но через год-два контора подрас https://opennet.dev/openforum/vsluhforumID3/50681.html#44 Mon, 23 Mar 2009 06:53:24 GMT В продолжении про "экономию".<br>Debian 4 + iSCSI. Штатное ядро не держит iscsi, надо обновлять. Обновил штатными средствами.<br>iSCSI заработал (на фоне freebsd уродство), ну да ладно.<br>Зато с новым ядром пропал маскарадинг, напрочь пропал.<br>весь файрвол, часть инет-сервисов, vpn-шлюз пошли лесом. Твою мать!! Хорошо что предварительно проверил на домашнем компе... Представил эффект от такого удаленного обновления.<br><br> https://opennet.dev/openforum/vsluhforumID3/50681.html#43 Mon, 23 Mar 2009 06:45:21 GMT &gt;Интересно а почему у меня nas на gentoo по iscsi работает ну <br>&gt;плюс cifs/ftp/afp и еще несколько веселых протоколов. <br>&gt;<br>&gt;и почему то никакого гемороя. <br>&gt;Зы контроллер рейда adaptec рейд на sas =) <br><br>Внимательнее читаем. У меня тоже все сервисы работают, проблема с КОНТРОЛЕМ ОБОРУДОВАНИЯ! (так видно?). <br><br>Это беда вседа всех никсов - обустраивается макушка айсберга (прикладное приложение, сервис, новое ядров даже и пр), но никто не задумывается о фундаменте - об ОБОРУДОВАНИИ. Что нужно его мониторить, ловить предупреждения, нужна превентивная диагностика, своевременное предупреждение, уведомления персонала. Драйвера ядра поддерживают почти все мыслимое на момент выхода железо, но приделать к ним уведомлялки о проблемах и мониторинг никто не думает. Это говорит, что разработчики понятия не имеют о промышленном применении своих продуктов, для дома или мелкой конторы это приемлемо, а для средней или с удаленной поддержкой уже нет. Надо изобретать скрипты на коленках, тратить драгоценное время (т.е. хуже чем https://opennet.dev/openforum/vsluhforumID3/50681.html#42 Fri, 20 Mar 2009 23:51:23 GMT Чистой воды брехня. Вы, батенька, Вин-бот. Это довольно тривиальная задача и решается она без всяких сложностей. Это, конечно, не умаляет возможностей платных решений. Но если они по какой-то причине недоступны, почему бы и самому не сделать?<br> https://opennet.dev/openforum/vsluhforumID3/50681.html#41 Fri, 20 Mar 2009 13:59:01 GMT SCADA ни когда не были узконишевыми решениями. Оторвитесь на минуту от IT и загляните в <br>АСУТП.... Хлебушек/колбаску/молочко... кушаете, в доме живете (а не на улице), на транспорте катаетесь, телевизор спотрите, за компьютером сидите...?<br>А вы думаете оно само вот так взялось и появилось из неоткуда?<br>Видать Вы даже не представляете о чем идет речь - жаль. <br><br>Ну если Вы сильны как специалист, то что Вы можете порекомендовать<br>для оборудования известных производителей (например SIEMENS/OMRON/ALLEN BRADLEY/MITSUBISHI...), а не самопала, на базе Linux/FreeBSD.<br>Требования к SCADA системе:<br>1) Минимизация времени разработки (это тоже деньги и немалые)<br>2) Минимизация времени восстановления после отказа (кто будет восстанавливать и плясать с бубном, если моя фирма находиться в 2000 км, а сбой произошел в 3 часа ночи - местные киповцы?)<br>3) Минимизация времени расширения работающей системы на объекте.<br>4) Минимизация времени замены оборудования (контроллеров/плат...)<br>5) Минимизация времени обучения разработчико