12 02 2015
Только а также минус у предоставленной топологии имеется: так как основа данных юзеров располагаться в контроллере сектора, то утрата связи с ним приводит к нарушению обычной работы присоединенных к контроллеру точек прохода.
3-ий вариант топологии преимуществен для огромных территориально распределенных объектов с единым центральным кабинетом.
В этой топологии один из осмотренных больше вариантов сформирует кластер единичной местности, а больше в иерархии располагаться сервер кластеров, кой владеет слабенькую информационную ассоциация с каждым из кластеров. На верхнем уровне может никак не существовать (а также вероятно никак не обязано существовать) доступа ко всем деталям нижнего уровня, но имеется вероятность обретать с нижнего уровня разные отчеты, посылать данные для юзеров а также т.д.
Теоретически над уровнем сервера кластеров может находиться сервер последующего, наиболее высочайшего уровня – все зависит от структуры эксплуатирующей СКУД фирмы а также организации в ней бизнес-процессов.
Мало о серверах
Говоря о программном уровне сетный СКУД, мы пока упустили отображение ролей используемых на этом уровне ресурсов, упоминая лишь обобщенные рабочие станции. В самом деле, ситуация тут незначительно труднее. На взгляд функционала позволительно отметить некоторое количество типов компов:
1. Серверы оснащения. Это те ПК, к коим конкретно (с использованием старенького хорошего RS-485) либо сообразно козни Ethernet подключены аппаратные контроллеры, специализирующиеся сервисом точек прохода.
2. Сервер базы данных. Как говориться случае это умышленно назначенный для этих целей комп, при этом поставленная на нем система управления базами данных может трахать все потребности организации, но не лишь СКУД.