Что мы забыли сказать.
Дата публикации: 30.09.2011

Отвечаем на поступившие вопросы о резервировании сетевых ресурсов.

Пробила! – так можно сказать про последнюю статью. Иногда наши новости идут почти без обратной связи, хотя это не значит, что они не задевают – все равно подписчики принимают к сведению и периодически в разговоре припоминают. Но бывает, как эта, пробивает в глубину, вызывая массу откликов. После нее нашу службу техподдержки взорвали вопросами, на основные из которых мы решили ответить общей статьей.

Небольшое замечание: почему-то по всей стране отмирают форумы, когда-то пользовавшиеся ажиотажем. Длинным дискуссиям народ стал предпочитать обращение напрямую к людям, которые могут дать прямой ответ. То ли менталитет поменялся, то ли делом все занялись. Перейдем к системе оффлайн.

1.(А. Сенченко, печатается без исправлений.) Понятно, что речь идет исключительно о сетевых проблемах, но хотелось бы контролировать их как-то глубже. Компьютер может доступен в сети, но все равно висеть. Понятно, вещь редкая, но мы же говорим об исключительной надежности.

Ваше желание оправдано, и нет ничего невозможного. Статья затрагивала лишь общую суть контроля. Если Вы откроете Параметры языка логики SL++, то увидите весь список того, на что можно поставить контроль. Мы это не стали перечислять, чтобы не утомлять читателей, и так замученных нашими новостями. Язык SL++ настолько прост, что нужно только сделать выбор из предложенных вариантов. Писать самому ничего не надо – это не С++. В списке серверов сначала находите нужный сервак, потом в списке событий выбираете нужное Вам событие. Например, Вы можете контролировать самое последнее звено живучести – есть ли запись на диск, выбрав строку «Ошибка записи».

error.jpg

Или попроще – отсутствие видеосигнала по камере.

error_signal.jpg

2. (Г. Солобода, печатается без исправлений.) Мне кажется, вы не до конца верно понимете процесс резервирования. Все это конечно хорошо, но если б вы знали всю теорию вопроса, то понимали бы, что нужно страховать дальние узлы, а не соседние, как у вас сказано. Есть целая наука, где изучаются перекрестные проверочные переплетения. И лучший метод в ней – межконтрольные лучи самого дальнего расстояния. Берете схему топо сети и находите все пары с наибольшим удалением, вот так по ним и должен осуществляться контроль. Называется метод Рихтера.

К сожалению, мы не нашли информации по господину Рихтеру, но ответ наш не сильно отличается от предыдущего. Статья говорила об общих аспектах, слово «соседи» употребляется в общем плане. Для сетевых элементов GOALcity нет никакой разницы, где находится этот сосед: в ближайшей комнате или на Брайтоне. Вы можете выбрать любой сервер для контроля, который есть в сети. Что касается метода некого Рихтера, то сам принцип имеет право на жизнь, и, наверное, ваше замечание будет полезно пользователям. Хотя в каждом конкретном случае нужно смотреть индивидуально, ориентируясь на вероятные уязвимости сети.

3. Странная разница между надежным контролем и паранойей. Вы предлагаете проверять только пару компов, вместо всех 100. Не внял где тут надежность.

Все нормально. Честно говоря, сходу мир нельзя объять и некоторые величины непонятны сразу – пока не посчитаешь. Но в статье есть приписочка – это математика. К сожалению, в широкой публицистике нам не разрешают делать непонятных выкладок, поэтому приведем лишь конечные результаты.

Если отсутствует контроль, то по теории вероятности при условиях периодического отказа сети вероятность выпадания записи - 1 к 800 (кругло) или лучше привести более понятную цифру, вы будете терять по 40 минут записи ежедневно. Все это в среднем и условно, просто, чтобы было некое понимание.

Если каждый компьютер будет контролить хотя бы один комп, то эта цена 1:134094402, выпадение по 2 минуты 16 секунд ежедневно.

Если по два, то 1:879893000345803298404, соответствует 0,6 секундам.

Уменьшать эту вероятность конечно можно, и несложно. Пожалуйста, в GOALcity нет ограничений. Просто смысла нет.

Спасибо за вопросы!

Как выжить в сети?
Для настоящей надежности электронная сеть должна быть похожа на природную, хотя бы на рыболовную снасть.
Резервирование каналов записи.
Автоматическое перераспределение ресурсов при авариях.