2014-02-12
563
О сетях и серверах
Техническая документация сети
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Климова Л.М. Си++. Практическое программирование. Решение типовых задач. – М.: КУДИЦ–ОБРАЗ, 2001.
2. Подбельский В.В. Язык Си++. – М.: Финансы и статистика, 1996.
3. Семакин И.Г., Шестаков А.П. Основы программирования: Учебник. – М.: Мастерство; НМЦ СПО; Высшая школа, 2001.
4. Шилдт Г. Полный справочник по С. 4-е издание.: Пер. с англ. – М.: Издательский дом «Вильямс», 2002.
5. Хьюз Дж., Мичтом Дж. Структурный подход к программир-ованию. М.: Мир 1980.
6. Стивен Прата. Язык программирования С++. Лекции и упражнения. К.: Издательство «ДиаСофт», 2001.
7. Дайнтбегов Д.М., Черноусов Е.А. Основы алгоритмизации и алгоритмические языки. М.: высшая школа 1992.
Если говорить о технической документации для использования внутри компании, то первое, что приходит на ум, это описание сетей и серверов. Как правило, принцип «одна компания – один сервер» уже мало где практикуется. Парки пользовательских машин увеличиваются, а вместе с ними растёт и количество используемых серверов. Уже никого не удивляет необходимость разделять почтовый и веб-серверы, находящиеся во внешней сети, и файл-сервер, не имеющий доступ наружу.
Точно так же, как увеличиваются и усложняются серверные парки организаций, увеличиваются и размеры сетей. Появляется большое количество активного и пассивного сетевого оборудования, нуждающегося в некотором уходе и внимании системного администратора. На пограничных соединениях появляются специализированные устройства, маршрутизаторы и firewall. Структура локальной сети может стать совсем запутанной, если вовремя не внести систему и порядок в неё.
Первое, что интересует каждого системного администратора, приходящего на новое место работы, это архитектура сети, которой ему предстоит заниматься. И далеко не всегда он может получить исчерпывающую информацию. Очень часто приходится слышать что-то вроде «тут у нас хабы/свитчи, тут розетки, а вон там провода». Это, конечно, крайне далеко от действительно полезной информации.
Поэтому, создавая документацию на сеть, стоит подходить к этому так, как будто вы хотите заново узнать то, чем владеете.
Ниже я перечислю те пункты, которые, на мой взгляд, наиболее интересны были бы мне, как новому сотруднику компании:
ü соответствие розеток к портам патч-панелей;
ü соответствие подключения портов патч-панелей к портам сетевого оборудования;
ü описание подключения на свитчах пользователей;
ü описание подключения на свитчах серверов и соединений между свитчами;
ü описание маршрутизации между сетевым оборудованием;
ü таблица используемых IP-адресов рабочими станциями;
ü графическая схема сети.
Разумеется, описать соответствие розеток с патч-панелями можно только в тех случаях, когда последние есть. Хочется верить, что в вашей компании они уже давно и успешно используются.
Описание подключения портов патч-панелей и свитчей необходимо вести в виде рабочего журнала, который дополняется и обновляется по мере переключений. Это нужно для полной ясности – что к чему подключено и как взаимодействует.
Под описанием подключения пользователей на свитчах подразумевается ваша схема разнесения рабочих станций по сетевому оборудованию. Предположим, что у вас в компании есть отдел дизайнеров, использующих в работе отдельный файл-сервер. (Отдельный, потому что размеры графических файлов весьма велики, и желательно их отделить от файлов обычных пользователей, чтобы последние не жаловались на чрезмерно долгое ожидание ответа сервера.)
Помимо использования файл-сервера для хранения своих наработок, дизайнеры зачастую обмениваются файлами большого размера между собой. Логично было бы подключить их на отдельный свитч.
Помимо самих предполагаемых дизайнеров, стоит на тот же свитч подключить и их файл-сервер, чтобы количество промежуточных соединений было минимальным. Это может оказаться весьма критичным для работы сети. (К слову, если фантазия на дизайнерах закончилась, то можно предположить разработчиков, использующих выделенный сервер баз данных.) Знать, к какому свитчу подключены серверы, полезно для анализа нестабильной и (или) медленной работы сети. Если у вас используется «интелектуальное» сетевое оборудование и особенным образом настроена маршрутизация, это также стоит описать. В будущем это может пригодиться для анализа работы сети. Или, например, при переезде компании в новый офис. К слову сказать, зачастую быстро и правильно (эффективно) переподключить всё оборудование на новом месте без чёткой документации практически невозможно. А следовательно, возникают дополнительные простои в работе компании и общий дискомфорт от «неправильно» работающей сети.
Табличка в виде «Пользователь – IP-адрес» (как вариант, можно добавить ещё и название рабочей станции) также не покажется лишней, когда количество сотрудников компании превысит 10-20 человек. Выдача IP-адреса новой рабочей станции не должна становиться для вас головной болью, а требуется для этого всего-навсего вести таблицу соответствий. Разумеется, задача может быть решена через DHCP-сервер, выдающий по MAC-адресам IP-адрес клиентам. Но если за пользователем закреплено несколько адресов или же по каким-то соображениям динамическая выдача адресов не используется, табличка окажется очень кстати. (Да и остальным она будет не лишней для более наглядного представления.)
Наглядно понять структуру всегда проще. Поэтому последнее, что хотелось бы упомянуть, – это графическая схема сети. Разумнее всего это делать на плане офиса. Здесь можно указать, как проложены кабели, где находится кроссировочный шкаф, где в комнатах установлены розетки и сколько их (причем не будет лишним указать не только розетки локальной сети, но и электрические). На этот же план можно нанести массу другой не менее полезной информации.
Разумеется, можно не ограничиваться перечисленными пунктами и дополнить свои. Но и перечисленного вполне достаточно для детального знакомства с вашей сетью.
