 |
|
|
|
Борьба за системные ресурсы
Борьба за системные ресурсы Как часто пользователи нашей сети жалуются нам, системным администраторам, на недостаточную производительность сервера, низкую пропускную способность канала и тому подобные вещи? И вот наконец-то руководство выделило кругленькую сумму денег на модернизацию наших серверов, но... пользователям опять мало. Что же делать? Без конца модернизировать сервер, угождая растущим с каждым днем запросам пользователей? Я не против модернизации, но только лишь в том случае, если она экономически оправдана. Попробуем проанализировать, из-за чего снижается производительность нашего сервера и сети в целом? Сейчас мы не будем касаться аппаратной стороны вопроса, а затронем лишь программную. В этой статье мы рассмотрим:
Будем предполагать, что у нас уже есть настроенный и функционирующий сервер на базе операционной системы Linux. Повышение производительности сервера Сначала попытаемся заставить наш сервер работать немного быстрее. Положительно на производительность любого компьютера влияют:
Конечно, кроме этих показателей есть еще и другие, но в нашем случае они не столь важны – ведь у нас же сервер. Хотя, если у нас сервер X-терминалов, то для нас будет важен объем видеопамяти и общая скорость работы нашей видеоподсистемы. Нужно заметить, что в случае с Linux объем оперативной памяти более важен, чем частота процессора. Итак, начнем по порядку. Замедлить быстродействие процессора может само ядро системы. Да, это так. Заметное снижение быстродействия может наблюдаться в двух случаях:
Обе эти проблемы не решить без перекомпиляции ядра. Вы ни разу не перекомпилировали ядро? Ничего страшного – все очень просто. Следуйте приведенным ниже инструкциям. Зарегистрируйтесь в системе как пользователь root и убедитесь, что установлены исходные тексты ядра и заголовки ядра (пакеты kernel и kernel-headers соответственно). Затем перейдите в каталог /usr/src/linux и выполните команду make menuconfig (см. рис. 1). Перед внесением изменений в файл конфигурации ядра, сохраните его под другим именем: Save Configuration to an Alternative File. Во время конфигурирования ядра вы можете включать или исключать некоторые функции из состава ядра или же сделать нужную вам функцию модулем, то есть в состав ядра данная функция включена не будет, но она будет использоваться при необходимости. Например, если вы добавите в систему устройство, то будет подключен нужный модуль, при условии, что вы его откомпилировали. Главная задача – повышение производительности системы, этого можно достичь, если точно сконфигурировать ядро и исключить из его состава ненужный код.
Рисунок 1. Программа конфигурации ядра make menuconfig Перейдите в раздел Processor type and features и установите нужный вам тип процессора. Следующая таблица поможет вам справиться с этой задачей: Таблица 1.Типы процессоров
Примечание. Ядро можно настроить для работы с другими процессорами, например, Ahtlon или Duron. Для этого просто выберите необходимый вам тип процессора. Если у вас многопроцессорная машина, включите поддержку SMP. Также очень рекомендую включить функцию MTRR. Включение этой опции может существенно повысить производительность системы. Кроме процессоров Intel данную возможность поддерживают процессоры и посторонних производителей: Cyrix 6x86, 6x86MX, MII, AMD K6-2 (stepping 8 и выше), K6-3, Centaur C6. Некоторые BIOS устанавливают MTRR для первого процессора, но отключают для второго. Активизация данной опции также решает и эту проблему. Затем можно просмотреть все остальные параметры ядра и отключить ненужные функции. Например, если у нас нет шины USB или она попросту не используется, зачем включать в ядро лишний код? Когда все устройства сконфигурированы, нужно сохранить файл конфигурации ядра и перейти непосредственно к этапу компилирования ядра. Введите команду: # make dep После завершения ее работы необходимо ввести команду: # make bzImage Если исходные тексты ядра и компилятор установлены корректно, то примерно минут через 20 (это зависит от версии ядра и от быстродействия вашей системы) вы получите откомпилированное ядро. Обычно оно помещается в каталог /usr/src/linux/arch/i386/boot. Примечание. Если в процессе компиляции вы получили сообщение о том, что не найден какой-то файл, то, скорее всего, вы отключили опцию, которая нужна для работы другой опции. Восстановите сохраненную конфигурацию ядра и попытайтесь откомпилировать ядро заново. Теперь следует откомпилировать модули, которые будут использоваться ядром: # make modules И установить их: # make modules_install Перед установкой модулей сделайте резервную копию модулей старого ядра (каталог /lib/modules). Теперь можно ввести команду: # make install Однако для установки только что созданного ядра я не рекомендую этого делать. Сначала нужно протестировать ваше ядро. С этой целью откройте в любом текстовом редакторе файл /etc/lilo.conf и добавьте в него следующие строки: image=/usr/src/linux/arch/i386/boot/bzImage label=my_linux # Параметры root и mem у вас, скорее всего, будут другими root=/dev/hda1 append=" mem=256M" read-only Потом введите команду lilo и перезагрузите систему. Попробуйте загрузить ядро. В случае возникновения ошибок вы всегда сможете загрузить старую версию. Надеюсь, что после проведенных действий ваша система стала работать быстрее. После рассмотрения оптимизации процессора, обратим наше внимание на оперативную память. Узнать информацию о загрузке оперативной памяти поможет команда free. Что больше всего «пожирает» оперативную память? Правильно, процессы! Одно дело, когда неблагодарный пользователь запустит большое количество процессов, но совсем другое дело, когда мы, администраторы, так нерационально используем наши ресурсы. Запустите конфигуратор setup и выберите пункт меню System Services (см. рис. 2). Если вы используете ОС Linux Mandrake, запустите конфигуратор drakxservices.
Рисунок 2. Системные сервисы Вам нужны все запущенные сервисы? Нет, так почему же они активны? Выключите все ненужные вам сервисы. Возможно, некоторые из них нужно запускать только в определенное время. Например, сервис ftp вам нужен только в рабочее время – незачем использовать ftp ночью. Или, наоборот, сервис ssh вам нужен только ночью, когда вам вздумается из дому изменить настройки сервера. Следующий фрагмент файла /etc/xinetd.conf разрешает использовать сервис ftp только в рабочее время, учитывая обеденный перерыв: service ftp { socket_type = stream wait = no user = root server = /usr/etc/in.ftpd server_args = -l instances = 4 log_on_success += DURATION USERID log_on_failure += USERID # Время работы сервиса access_times = 8:00-12:00 13:00-18:00 nice = 10 } Для остановки того или иного сервиса введите команду service <имя> stop. Например, service httpd stop. Примечание. Для запуска сервиса используется параметр start, а для перезагрузки – restart. Вы отключили все, что можно, а памяти все равно не хватает? Тогда вам можно посоветовать только модернизацию оперативной памяти. А пока можно создать файл подкачки, который немного отложит покупку памяти. Например, если вы хотите создать файл подкачки размером 128 Мб, выполните следующие действия:
dd if=/dev/zero of=/swap bs=1k count=131072 Данная команда создаст пустой файл /swap размером 128 Мб.
mkswap /swap 131072
swapon /swap
Третью команду нужно добавить в сценарий загрузки системы /etc/rc.d/rc.local, чтобы не вводить ее вручную при каждой загрузке сервера. Мы еще можем увеличить производительность жесткого диска. Тут нам поможет программа hdparm. Давайте попробуем немного «разогнать» наш жесткий диск. # hdparm - d1m2c3u1 /dev/hda Теперь разберемся, что же мы сделали этой командой. Во-первых, мы включили DMA, затем разрешили передавать более одного слова за такт, а также включили 32-битный доступ к диску (команда с). Для просмотра установленных параметров введите команду: # hdparm /dev/hda Запустим hdparm в режиме теста: # hdparm –t /dev/hda В зависимости от жесткого диска у нас должно получиться не менее 14 Мб/сек. Обратите внимание на опцию m2. Данная опция позволяет передавать более одного слова за такт – два слова (m2). Если у вас современный жесткий диск, установите максимальное значение – m16. Однако если после сохранения параметров на консоли появляется сообщение Drive Seek Error, уменьшите данное значение (например, до восьми блоков за такт). Можно использовать параметры X33 и X66 для включения режимов передачи данных UDMA33 и UDMA66 соответственно. Если при использовании режимов Х33 и Х66 производительность снизилась, используйте режим Х68. Для сохранения параметров контроллера IDE используйте команду: # hdparm -k1 /dev/hda При перезагрузке системы параметры IDE теряются, поэтому команду «разгона» винчестера нужно поместить в сценарий запуска системы. Сейчас просто добавьте команду вызова hdparm в файл /etc/rc.d/rc.local. Этот способ является наиболее универсальным, поскольку он позволяет установить отдельные параметры для разных жестких дисков, если у вас их несколько. Второй, менее универсальный способ заключается в редактировании файла /etc/sysconfig/harddisks, в котором можно задать общие параметры для всех жестких дисков. Есть еще один «подводный камень», который состоит в следующем: при пробуждении системы и её переходе в нормальное состояние после «сна» параметры контроллера также сбрасываются. Этого можно избежать, если подправить файл конфигурации демона apmd, который отвечает за управление питанием. Параметры контроллера IDE, которые устанавливаются при переходе системы в «спящий» режим и выходе из него, задаются строками HDPARM_AT_SUSPEND и HDPARM_AT_RESUME в файле конфигурации /etc/sysconfig/apmd. Мы сделали все возможное, чтобы наш сервер работал быстрее. Теперь попробуем ограничить пропускную способность канала. Ограничение пропускной способности канала с помощью Squid Для этого нам понадобится уже настроенный и работающий прокси-сервер Squid (сервис Squid). Предположим, что нам нужно настроить прокси-сервер таким образом, чтобы одна группа компьютеров могла работать с одной скоростью, а другая – с другой. Это может потребоваться, например, для разграничения пользователей, которые используют канал для работы (например, вы), и пользователей, которые используют ресурсы канала в других целях. Естественно, первым пропускная способность канала важнее, чем вторым. С помощью прокси-сервера Squid можно разделить канал. Для начала в файле конфигурации (/etc/squid/squid.conf) укажите, сколько пулов, то есть групп пользователей, у вас будет: delay_pools 2. Затем определите классы пулов. Всего существует три класса:
В файл squid.conf добавьте следующие директивы: delay_class 1 1 # определяет первый пул класса 1 для домашних пользователей delay_class 2 2 # определяет второй пул класса 2 для служащих Теперь задайте узлы, которые будут относиться к пулам: acl home src адреса acl workers src адреса delay_access 1 allow home delay_access 1 deny all delay_access 2 allow workers delay_access 2 deny all Затем укажите ограничения: delay_parameters 1 14400/14400 delay_parameters 2 33600/33600 16800/33600 Как я уже отмечал выше, для пула класса 1 используется одно ограничение для всех компьютеров, входящих в пул – 14400 байт. Первое число задает скорость заполнения для всего пула (байт/секунду). Второе – максимальное ограничение. Для пула класса 2, соответственно, используются ограничения на всю подсеть и отдельно на каждого пользователя. Борьба со спамом Вы опять получили письмо с предложением купить базу данных абонентов МТС? Добавьте адрес спаммера в «черный» список – в файл /etc/mail/access. Данный файл преобразуется в файл access.db, который используется программой sendmail. В нем вы можете указать узлы, которым разрешено (запрещено) использовать ваш SMTP-сервер. Формат этого файла такой: узел | сеть | пользователь | действие. localhost.localdomain RELAY localhost RELAY 127.0.0.1 OK spammer@spam.ru REJECT spamworld.com ERROR:"550 Access denied" 192.168.1 RELAY host.mydomain.ru REJECT mydomain.ru RELAY В первой-третьей строках мы разрешаем самим себе использовать SMTP-сервер. Затем мы запрещаем пересылку почты пользователю spammer@spam.ru, а также всему домену spamworld.com. Шестая строка разрешает пересылку почты всей нашей локальной подсети – 192.168.1.*. Последняя строка разрешает использовать SMTP-сервер нашему домену, а предпоследняя запрещает использовать наш сервер одному узлу из домена mydomain.ru – host. Разница между действием OK и RELAY заключается в том, что в первом случае (ОК) пересылка разрешается, даже если другие правила sendmail запретили пересылку почты, например, если имя узла не разрешено (при использовании DNS). Для запрещения пересылки можно просто использовать REJECT. Тогда пользователь увидит сообщение «Access denied». Действие ERROR более информативно, так как вы можете указать любое свое сообщение (установить реакцию на ошибку). Действие ERROR можно записать по-другому: ERROR:D.S.N:Message, где D.S.N – это код ошибки в соответствии с RFC 1893. Для того чтобы новые правила доступа вступили в силу, введите команду: # makemap hash /etc/mail/access < /etc/mail/access Изменения вступят в силу сразу после завершения работы программы makemap. Перезагружать sendmail при этом не нужно! Ограничение действий пользователей Иногда нужно запретить некоторым узлам (или целым подсетям) доступ к вашему серверу. Зачем пользователям из соседнего отдела пытаться зарегистрироваться на вашем FTP-сервере? Ясное дело, что FTP-сервер не позволит им этого сделать, поскольку они не знают, точнее, не должны знать имя пользователя и пароль для доступа к этому серверу. Так зачем же нам разрешать доступ к FTP этим пользователям, если мы заведомо знаем, что им там делать нечего? Демон tcpd аутентифицирует удаленных пользователей и проверяет корректность их запросов. С помощью этого демона можно ограничить запросы с удаленных компьютеров. Файл hosts.allow содержит список хостов, которым разрешено подключаться к вашей системе, а hosts.deny – запрещено. Записи имеют формат: служба:хост.домен. Если вы хотите разрешить или запретить доступ всем, используйте модификатор ALL. Запись ALL:ALL открывает или закрывает доступ к вашей машине всем компьютерам для всех видов сервисов. Ниже приведен листинг файла hosts.allow. ftp:our_domain.firma.ru В вышеприведенном листинге доступ к ftp разрешен только нашему домену our_domain.firma.ru. В файл hosts.deny рекомендуется добавить запись, запрещающую доступ к FTP соседям (другому отделу) или же абсолютно всем (ftp:ALL) Раз уж мы заговорили о FTP-сервере, нельзя не сказать, что все приведенные выше операции можно было реализовать средствами самого сервера, но я не вижу смысла загружать сервер лишней работой, если все это можно сделать на более низком уровне. Но для полноты обзора все же рассмотрим директиву Limit, ограничивающую доступ к серверу: <Limit LOGIN> DenyAll AllowUser pupkin MaxClients 5 Deny from 153.111.171.137 Deny from 192.168.2. </Limit> Первая директива в блоке Limit запрещает регистрацию (LOGIN) всем пользователям, вторая разрешает только регистрацию пользователя pupkin, третья – задает максимальное число клиентов (5). Последние две директивы запрещают регистрацию с узла 153.111.171.137, а также из подсети 192.168.2. Кроме директив DenyAll и AllowUser существуют противоположные им по действию – AllowAll и DenyUser соответственно. Данный блок Limit нужно указать в файле конфигурации сервера ProFTPD – /etc/proftpd.conf. Теперь, когда пользователи других подсетей не смогут использовать наши ресурсы, немного ограничим своих родных пользователей. Для ограничения локальных пользователей используются файлы:
Эти файлы расположены в каталоге /etc/security. Первый файл – это таблица доступа пользователей. Когда кто-то регистрируется в системе (удаленно или локально), в этой таблице система ищет запись, содержащую имя пользователя и предоставляет соответствующий этому пользователю доступ или вообще запрещает его. Если имя пользователя не найдено, но может регистрироваться со всех терминалов (для локальной регистрации) или со всех узлов (для удаленной регистрации). Формат файла access.conf такой: Разрешение:Пользователи:Доступ. Первое поле может содержать либо символ «+», который означает, что доступ разрешен, или символ «-», запрещающий доступ. Поле Пользователи содержит список имен пользователей, разделенных пробелами. Можно указывать имя пользователя в формате user@host. Такая запись описывает пользователя user, который регистрируется из машины host. Для обозначения всех пользователей можно указать ALL в качестве значения второго поля. Третье поле (Доступ) может содержать список терминалов, из которых разрешена (или запрещена – в зависимости от значения первого поля) регистрация пользователей (для локальной регистрации). Если вас интересует регистрация по сети, вы можете указать здесь имя узла, IP-адрес узла, адрес сети (заканчивается точкой), имена доменов или имена узлов локальной сети (не содержат точки). Для обозначения всех узлов локальной сети можно использовать модификатор LOCAL. Можно также использовать модификатор EXCEPT (кроме) для исключения некоторых элементов списка (во втором и в третьем полях). Рассмотрим несколько примеров: -:ALL EXCEPT den user serge:LOCAL .microsoft.com +:reboot shutdown:LOCAL +:root:tty1 -:root:LOCAL -:den user serge:LOCAL EXCEPT host1 Первое правило запрещает регистрацию всех пользователей, кроме (EXCEPT) den, user, serge из любого хоста локальной сети и домена .microsoft.com. Но эти пользователи могут регистрироваться из любого другого домена. Второе правило разрешает регистрацию пользователей reboot и shutdown из любого узла локальной сети. Третье правило разрешает регистрацию пользователя root из терминала tty1, а следующее правило – запрещает регистрацию пользователя root по сети (локальной). Последнее правило запрещает регистрацию пользователей den, user, serge из любого узла локальной сети, кроме узла host1. C точки зрения безопасности приведенные примеры не имеют никакого смысла. Я привел данный пример только в демонстрационных целях. Как видно из имен пользователей во втором правиле, первый используется для перезагрузки системы, а второй – для ее останова. То есть при регистрации этих пользователей система соответственно или перезагружается, или останавливается. Подобное практикуется многими системными администраторами, которых я знаю. Как они говорят, этих пользователей создали для удобства: если нужно перезагрузить машину, нужно просто войти в систему под пользователем reboot. Такое удобство вам может дорого обойтись, если кто-то, узнав ваш пароль, остановит машину во время вашего отсутствия, поэтому не рекомендую вам создавать подобных пользователей вообще. Третье правило разрешает регистрацию пользователя root с терминала tty1 (локальная регистрация), но не запрещает регистрацию со всех остальных. Можно было бы указать правило -:root:ALL перед третьим правилом, но специально для этих целей служит файл /etc/securetty, о котором мы поговорим немного позже. Теперь перейдем ко второму файлу – console.perms. Этот файл определяет полномочия привилегированных пользователей, которые будут им присвоены при регистрации через консоль системы (локальная регистрация). Скорее всего, вам не нужно будет редактировать этот файл. После внесения изменений в этот файл выполните команду: pam_console_apply -r Обычно данная команда помещается в один из инициализационных сценариев системы. Для получения более подробной информации обратитесь к справочной системе. В файле limits.conf определяются квоты системных ресурсов, например, максимальное число процессов или максимальное время процессора. Прежде чем ограничить пользователей, рассмотрим, как можно ограничить самого себя, то есть пользователя root. В файле /etc/securetty, который уже упоминался выше, указываются терминалы и виртуальные консоли, из которых может регистрироваться пользователь root. Я рекомендую вообще запретить регистрацию пользователя root из консоли. Для этого удалите (или закомментируйте) все строки в файле securety. Если вам будут нужны максимальные привилегии, используйте команду su (super user). После ввода этой команды программа запросит у вас пароль пользователя root, и если пароль правилен, вы получите привилегии пользователя root. В файле limits.conf определяются ограничения ресурсов системы для пользователя или группы пользователей. Формат файла такой: . Первое поле (domain) может содержать:
Второе поле – это тип ограничения: мягкое (soft) или жесткое (hard). Мягкое ограничение определяет число системных ресурсов, которое пользователь все еще может превысить, жесткое ограничение превысить невозможно. При попытке сделать это, пользователь получит сообщение об ошибке. Элементом ограничения (item) может быть:
Рассмотрим несколько примеров. Например, нам нужно установить максимальное число процессов для пользователя user. Это можно сделать с помощью таких записей: user soft nproc 50 user hard nproc 60 Первая строка определяет мягкое ограничение (равное 50), а вторая – жесткое. Допустим, у нас есть группы dialup1 и dialup2. В каждую группу входят 30 пользователей. У нас есть всего 30 входящих линий, поэтому нужно обеспечить одновременную работу не более 15 пользователей из каждой группы. Это делается так: @dialup1 - maxlogins 14 @dialup2 - maxlogins 14 В первом и втором случае из каждой группы пользователей одновременно работать смогут не более 15 (maxlogins 14 – отсчет начинается с нуля). При регистрации шестнадцатый пользователь увидит сообщение: Too many logins for «dialup1». Последнее, что можно сделать, – это установить квоты для файловых систем, но квотирование выходит за рамки этой статьи (вполне возможно, что квоты будут рассмотрены в следующей моей статье). Все ваши вопросы, комментарии и пожелания присылайте на адрес dhsilabs@mail.ru. |
ДЕНИС КОЛЕСНИЧЕНКО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
