?

Log in

No account? Create an account
Active Direcity нужна ли эта система сейчас?
rubuntu
AD - служба каталогов позволяющая: управлять пользователями и группами пользователей; распределять доступы к файлам, устройствам и т.д.; централизованно устанавливать обновления и сторонее ПО; хранить информацию о пользователях и их настройках. Это чуть ли не стандарт во многих компаниях нашей необъятной страны.
Зачем это нужно? Хочу спросить не зачем нужно, например, управлять доступом пользователей, а зачем это нужно с точки зрения организации рабочего процесса на современном предприятии? Именно под эти углом хочу рассмотреть AD, т.к.компании нужены компьютеры, ПО, сотрудники для организации работы, которая направленна на получение прибыли компании.
1. Распределение доступа к файлам.
Распределять доступ к файлам и папкам это удобно. Например, бухгалтерия хранит файлы на в папке Fin на неком сетевом диске. Туда имеет доступ только группа из бухгатеров и несколько директоров, а остальные не должны иметь доступа.
Отличное решение, именно так и был организован процесс 10 лет назад. Сейчас появились системы документооборота. Они точно хранят документы, распределяют права доступа к ним, но кроме этого делают систему маршрутизации документооборота и управление заданиями.
Пример.
Решаем некому сотруднику повысить з.п., начальник отдела, где работает сотрудник, создает прошение по повышении своему директору и нажимает кнопку отправить на согласование своему директору, тот отправляет в бухгалтерию, а она уже отправляет гендиректору на утверждение. В системах документооборота это занимает несколько минут, у каждого из этой цепочки появляются соответствующие задания, чтобы не забыть. А сколько бы это заняло в путем обмена файлами? Еще нужно каждому из этой цепочки написать письмо или напомнить, чтобы напомнить.

Именно системы документооборота вытеснили обмен документов через общие файлы и папки. Зачем еще нужны файлы и папки? Хранить фотографии с последнего корпаратива, интересную киношку которую хочется показать коллегам или тонны музыки? Все это не относится к работе, но если так нужно, то системы документооборота позволяют хранить разную информацию, так что можно это засунуть туда. Так что удаленные файлы и папки особо не нужны современному бизнесу, т.к. есть другие более совеременные инструменты.
2. Установка ПО и обновлений.
Что обычно устанавливают Office и антивирус. Они прекрасно ставятся удаленно, но установка спецефического ПО часто проще делается напрямую. Мне один админ жаловался, что при установке Zlock (ничего не хочу сказать, хорошая программа) из сотни компьютеров встала только на половину, на остальных с разными ошибками отказалась, а на трех привело к краху винды и пришлось полностью переустанавливать их.
Можно ведь ПО не устанавливать, а удаленно доставлять или те же системы документаоборота, которые имеют обычно все, что нужно для работы. В крупные компании обычно поставляются компьютеры у уже предустановленным ПО. AD для обновлений вообще не нужен.
3. Информация о пользователях и настройках.
А что хранить, если все что нужно лежит в системе документооборота для каждого пользователя. Есть секретные данные? Для этого существуют системы шифрования дисков, флешек, папок, в качестве ключа использовать etoken.
4. Управления пользователями и группами.
Управлять то особо получается нечем. Но если все-таки нужно централизованно это делать, то есть LDAP.
Обращаясь к прошлому посту, в общем и целом инфраструктура компании на основе Windows и Active Directory не нужна. Системы документооборота попросту уничтожили AD. А есть и более мощные решения например системы управления предприятие.
Стоит заметить, что сущестувуют компании которые уже не смогут отказаться от Microsoft, например, те, что внедрили Axapta.
P.S. Этот пост всего лишь мнение автора и попытка взглянуть на Active Directory с другой точки зрения.

Винды
rubuntu
Почему бизнес выбирает Windows?
Под бизнесом я буду говорить об обычном бизнесе, малый или средний - не важно.
Десять лет назад, или даже пять, такой вопрос был бы странным. Решил разобраться, почему до сих пор выбирают Windows, а не другие решения. Кроме альтернативы в виде Linux существует и другие системы, например Mac и набирает популярность Android. Опросил своих знакомых бизнесменов. Получил несколько причин, чем с Вами и делюсь.
1. Привычка.
Да, привычка - дело сильное. Из-за этого, решения по замене любимого Windows и Office на что-то другое, терпят неудачу. Начинают ныть все сотрудники вместе взятые. Но при сильной поддержке этого перехода со стороны руководства нытье прекращается. На сэкономленные деньги можно премию какую дать, или наоборот, у особо плаксивых отобрать. Способов много, было бы желание. А желание должно исходить от руководства. 5-10 лет назад это желание исходило только снизу - от системных администраторов, сейчас многие руководители осознают и хотят перейти на что-то другое. А многим руководителям компаний нравится Mac, Ipad, Iphone, подумывают об Android и даже присматриваются к Linux. В итоге получается, что привычка это не причина.
2. Office.
Во многих компаниях привыкли к ворду и екселю, за уши не оттащишь. Десять лет назад альтернативы - не было. Пять лет назад OpenOffice был откровенно говоря не очень, а текстовый редактор на Mac`ах был еще не популярен, в силу отсутствия популярности самих Mac`ов. Сейчас OpenOffice достойно работает, Excel и Word без проблем может заменить. Огромное количество систем документооборота, вообще, не требуют использования Office. Все что нужно для создания документов уже есть внутри в виде различных встроенных редакторов на основе веб интерфейсов. Есть компании, которые жестко завязаны на Excel, различными формами отчетности, тогда переход для них не возможен. Так что Office в целом не причина.
3. Бухгалтерское ПО.
Здесь правит 1С, но оно прекрасно работает под wine Linux, можно взять не чистый wine, а например, Ethersoft wine, стоит он копейки. Так что вопрос с главной бухгалтерской программой тоже решен.
4. Специализированное ПО.
Этому есть много аналогов под другие ОС. Под Mac Вы точно найдете нечто аналогичное. Часто тыкают Autocad`ом. Но Autocad есть под Mac. Вообще под Mac, что касается графики есть все, что нужно.
5. Банк-клиент.
Специально оставил этот пункт последним. Банк-клиент - это контроль за финансовой составляющей компании, которая является одной из самых главных частей бизнеса и руководитель компании обязан этот контроль иметь. Большинство банк-клиентов в нашей стране не работает с другими ОС, кроме Windows. Собственно и в Windows они работают достаточно тяжело. Нужно убрать огромное количество настроек безопасности, чтобы требуемый объект ActiveX стал правильно работать под Explorer`ом. Банк-клиент работает не только у бухгалтеров, но и директор компаний, которые подписывают созданные бухгалтерами платежки. Поэтому руководитель обязан иметь компьютер на базе windows. Бухгалтерия тоже обязана его иметь. Ну а раз у руководителя предприятия Windows, до желания со стороны руководства перейти на что-то иное резко убавляется. Именно этот пункт, со слов руководителей компаний и владельцев бизнеса является самым пугающим для них. А так, многие из них готовы перейти.
Вывод.
Компании готовы перейти на что-то отличное от Windows. Есть мотивация, особенно у представителей малого бизнеса (число сотрудников - до 50 человек). Но основная причина, которая отталкивает это банк-клиент.
Мне интересно, почему нельзя сделать банк-клиент под несколько систем? Ведь в последнее время подавляющее число банк-клиентов работают в браузерах. Не так уж и сложно адаптировать его под другой браузер или я ошибаюсь?

Настройка HAST
rubuntu
Введение.
HAST (Highly Avalible Storage) технология позволяющая создавать отказоустойчивые хранилища (Primary-Secondary) используя несколько машин. Эта технология может помочь при создании кластера высокой доступности (HA). HAST появился в FreeBSD начиная с 8.1. В текущей версии HAST можно использовать только две машины. HAST работает на уровне блоков и не зависит от файловой системы, т.е. можно использовать ZFS или UFS.

Эта технология работает по TCP. Для работы используется демон hastd и утилита для управления hastctl.

Использование.
Имеем две машины (ноды)
host1 192.168.1.2
host2 192.168.1.9
на обоих машинах стоит дополнительный диск ad3.
HAST готов к использованию сразу, без дополнительных установок. Для конфигурирования создадим файл /etc/hast.conf
resource my {
        on host1 {
                local /dev/ad3
                remote 192.168.1.9
        }
        on host2 {
                local /dev/ad3
                remote 192.168.1.2
        }
}
т.е. host1 имеет диск ad3 и синхронизируется с 192.168.1.9 (host2), а для host2 соответственно наоборот.
Сделайте такой же файл на другой машине.
host1# hastctl create my
host1# hastd
После этого демон должен запустится, проверим, что все работает
host1# hastctl status
должно выдать вроде этого
my:
  role: init
  provname: my
  localpath: /dev/ad3
  extentsize: 0
  keepdirty: 0
  remoteaddr: 192.168.1.2
  replication: memsync
  dirty: 0 bytes
Сделаем такие же действия на другой машине
host2# hastctl create my
host2# hastd
Теперь раздадим роли машинам. Например, host1 будет главным, а host2 - резервным.
host1# hastctl role primary my
host2# hastctl role secondary my
После того, как host2 стал secondary, должна начаться синхронизация. В первый раз она не должна занять много времени.
Проверим, что все работает.
host1# hastctl status
my:
  role: primary
  provname: my
  localpath: /dev/ad3
  extentsize: 2097152
  keepdirty: 0
  remoteaddr: 192.168.1.9
  replication: memsync
  status: complete

  dirty: 0 bytes
Для нас важно, чтобы был статус complete. Если статус другой, проверяем, что не так.
Теперь создадим файловую систему. Не смотря на то что можно использовать UFS лучше использовать ZFS, чтобы не приходилось запускать fsck.
Создадим пул используя появившееся устройство /dev/hast/my
host1# zpool create mydisk /dev/hast/my
host1# zpool list
NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
mydisk    95G  84.5K    95G     0%  ONLINE  -
На второй машине этого делать не надо.
HAST настроен.

Тестирование.
Создадим несколько файлов в mydisk и протестируем нашу систему. Для тестирования перезагрузим ноду с primary, т.е. host1.
После перезагрузки посмотрим состяние пула
host1# zpool list
NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
mydisk    -               -             -         -      FAULTED          -
Это случилось потому что пропало устройство /dev/hast/my Экспортируем пул и поменяем роль host1 на secondary
host1# zpool export -f my
host1# hastctl role secondary my
А host2 сделаем основным и импортируем пул.
host2# hastctl role primary my
host2# zpool import -f mydisk
host2# zpool list
NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
mydisk    95G    84.5K    95G     0%    ONLINE          -
Проверим наши файлы, они должны остаться.

Ошибки.
По умолчанию логи можно посмотреть в /var/log/message.
В результате некоторых действий можно добиться ситуации, когда вы обнаружите в логах запись Split brain - разделение сознания.
Это означает, что каждая из нод думает, что она главная и живет собственной жизнью. Такое может произойти если вы умудритесь
записать разную информацию на нодах или поставить обои машины в роль primary. Исправить эту ситуацию можно выбрав ту машину которая будет у вас secondary, и нужно сделать на ней:
 hastctl role init my
 hastctl create my
 hastctl role secondary my
После этого должен запуститься процесс синхронизации. Он может занять продолжительное время.
 

Автоматизация.
Эта система сделана для кластеризации, а именно для кластера высокой доступности. Например можно воспользоваться CARP 
чтобы сделать постоянным. Можно написать собственные скрипты,
 а можно воспользоваться стандартными. Автором HAST уже написаны готовые скрипты которые умеют определять на какой ноде сейчас primary.
Для работы следует установить ucarp:
cd /usr/ports/net/ucarp
make && make install clean && rehash
Скрипты находятся в /usr/share/expamles/hast/
Скопируйте их в /домашний каталог/sbin/hastd/ так предлагается по умолчанию и отредактируйте переменные в начале скриптов
ucarp.sh, ucarp_down.sh, ucarp_up.sh
Сделейте это на обоих нодах и запустите ucarp.sh на обоих нодах.

Дополнительные возможности.
У HAST существует три типа репликаций. Они различаются тем когда данные считаются записанными.
  • memsync - Данные операции записи считаются завершенными когда запись локальна завершена и когда удаленный узел принял данные, но до того как записать данные. Данные на удаленной ноде начинают писаться, как только отправлен ответ.
  • fullsync - Данные операции записи считаются завершенными когда запись завершена локально и на удаленной ноде запись тоже завершена.
  • async - Данные записи считаются завершенными когда запись завершена локально. Это наиболее быстрый способ записи.
На момент написания статьи работает только memsync.
Дополнительную информацию можно прочитать на http://wiki.freebsd.org/HAST

Заключение.

HAST только появился, у него богатые возможности для организации хранилища высокой доступности. В данный момент еще не все работает, но это хорошее начало для кластеризации на FreeBSD.
Перед тем как работать с HAST в боевых условиях рекомендую потренироваться. У меня были ситуации, когда secondary не хотел брать данные с primary, было что неаккуратные движения приводили к "Split Brain". Данные, правда, потеряны не были, но много времени было потеряно на синхронизации.

 
 



Статья написана при поддержке компании Uniadmins.

(no subject)
rubuntu
CARP

Введение.
На самом деле не так часто настраиваю carp и от времени забываются мелочи, поэтому написал несколько заметок для себя, которые потом оформил. Эта статья максимально краткая по настройке carp под FreeBSD.
CARP (Common Address Redundancy Protocol) - протокол избыточности общего адреса, который позволяет нескольким машинам иметь один ip адрес. Более подробно расписано в вики и приводить ее не вижу смысла.

Настройка.
Для его настройки нам понадобится добавить в ядро устройсто carp
Добавляем в файл ядра MYCONF строчку device        carp
cd /usr/src
make buildkernel KERNCONF=MYCONF
make installkernel KERNCONF=MYCONF
reboot

Далее создадим общий интерфейс для всех машин и сконфигурируем его:
host1# ifconfig carp0 create
host1# ifconfig carp0 vhid 1 advskew 1 pass 123456 192.168.1.10/24

vhid - идентификатор группы.
advskew - приоритет, чем он ниже, тем раньше в случае сбоя он станет основным.
Тоже самое сделаем на другом сервере:
host2# ifconfig carp0 create
host2# ifconfig carp0 vhid 1 advskew 2 pass 123456 192.168.1.10/24

Чтобы CARP работал в режиме резервирования надо включить net.inet.carp.preempt=1
host1# sysctl net.inet.carp.preempt=1
host2# sysctl net.inet.carp.preempt=1

Попробуйте с еще одной машины пропингвать 192.168.1.10. После этого выключите машину host1.
Пинг должен прерваться на некоторое время и опять продолжиться. Если так и произошло, то все настроенно верно.

Чтобы CARP работал в режиме распределения нагрузки на включить net.inet.carp.arpbalance=1
host1# sysctl net.inet.carp.arpbalance=1
host2# sysctl net.inet.carp.arpbalance=1

В этом случае при обращении к 192.168.1.10 сервер будут отзываться по очереди.

Сохранение настроек.

Теперь сделаем, чтобы после перезагрузки настройки сохранились.
добавим в /etc/rc.conf
cloned_interfaces="carp0"
ifconfig_carp1="vhid 1 advskew 1 pass 123456 192.168.1.10/24"

И добавим в /etc/sysctl.conf
net.inet.carp.preempt=1 или net.inet.carp.arpbalance=1 соответственно.
Сделать это необходимо на всех машинах.
Tags: ,

Тюнинг ZFS
rubuntu
Вообще говоря для ZFS рекомендуется более 8Гб оперативной памяти, чтобы она смогла себя раскрыть.
Но приходится настраивать ZFS на машинах с маленьким объемом оперативной памяти например с 1Гб и даже меньше. Минимальный объем который необходим для работы ZFS это 512Мб. Здесь я хочу привести несколько советов по тюнингу ZFS.
Что может быть если этого не сделать? Предположим Вы настроили ZFS на сервере с 1Гб оперативной памяти. Все загрузилось, но когда вы начинаете интенсивно работать с диском, система вдруг падает в kernel panic.
Чтобы этого не случилось необходимо дописать ряд параметров в /boot/loader.conf

vm.kmem_size_max="384M"
vm.kmem_size="384M"
vfs.zfs.arc_max="40M"
vfs.zfs.prefetch_disable=1

vm.kmem_size, vm.kmem_size_max - участок памяти используемый ядром для выделения памяти, например, при использовании malloc. Размер этой памяти виртуальный, но постарайтесь сделать его меньшим вашей оперативной памяти.
vfs.zfs.arc_max. Вообще ARC это то где  хранятся кешированные данные пулов (pool). Работа с этим параметров сказывается на производительности, но в случае если у нас памяти мало, то этот параметр можно уменьшить.
vfs.zfs.prefetch_disable=1 - отключение режима prefetch.  Режим prefetch - режим, когда система "угадывает" что будет прочитано и заранее читает, что может значительно ускорить работу файловой системы. На amd64 при памяти менее 4Гб он отключается автоматически.
Некоторые советуют отключить ZIL добавлением vfs.zfs.zil_disable="1". Не делайте этого! Отключение ZIL может помочь только в редких случаях, в большинстве случаев он приведет к резкой потере производительности.

Так же добавлю, что лучше для работы с ZFS иметь не менее 1Гб оперативной памяти и использовать amd64.
Для более глубокого тюнинга рекомендую ZFS Evil Tuning Guide



Рейтинги
rubuntu
Часто на сайтах сталкиваешься с рейтингами. Например, рейтинг постов или игрушек. В простом варианте за каждый понравившейся материал посетитель ставит +1, а за не понравившийся ничего не ставит.
Как сортируется по популярности? Кто больше набрал плюсов, у того и больший рейтинг популярности. У многих, даже весьма авторитетных сайтов, две кнопки отсортировать по популярности и по дате добавления, иногда по количеству просмотров. Но правильно ли использовать количество баллов рейтинга?
Предположим появился пост год назад и за него за него каждый день голосовало по несколько человек. В итого пост получил 700 голосов. Неделю назад появился не менее интересный пост и за него проголосовало 18 человек, а две недели назад за еще один пост проголосовало 65 человек. Какой пост более популярный?
Так вот на некоторых сайтах мы столкнемся с тем, что первый пост будет самым популярным.
А если посмотреть сколько пост набрал за некоторое время, например с начала опубликования.
Первый пост 700/365=1.91
Второй пост 18/7=2.5
Третий пост 65/14=4.64
Значит третий пост более популярный и его стоит поставить на первое место.
Более правильно будет вести таблицу в которую мы будем заносить id поста и дату голосования. После этого мы сможем посчитать за определенный период и можем получить, что например за неделю второй пост получил больший рейтинг. Для каждого сайта следует выбрать именно свой период за какой считать рейтинги.
Аналогично следует считать популярность.

Защита сервера от простых DOS
rubuntu
Введение.

Атаки типа DOS бывают различными. Здесь рассмотрю одну популярную атаку.
Смысл этой атаки заключается в создании большого количества соединений в которые ничего не передается, а которые просто висят открытыми продолжительное время. При этом атакующий постоянно пытается открыть новые. Соединения создаются на один открытый порт и соответственно от одного клиента. На каждое такое соединение запускается обработка его с помощью соответствующего ПО, которое использует до нескольких мегабайт памяти на каждое соединение. Таким образом 500 соединений пусть даже и по 2 мб, съест на сервере 1Гб оперативной памяти, а если их создавать быстро то еще и процессорное время и так вплоть до того что сервер перестает отвечать на запросы.
Программы которые это делают достаточно распространены, пользоваться ими просто, поэтому любой человек чуть знакомый с компьютерами может ей воспользоваться. Кроме этого для таких типов атак достаточно очень слабого интернет канала, буквально в несколько кб/c. Учитывая эти два фактора вашему серверу могут доставить серьезные неудобства.

Защита.

Поняв как работает атака достаточно ограничить количество соединений от одного клиента.
Для удобства зададим макросы:
port = "{ smtp http https ssh }"
int_wan="em0"

Собственно само правило:
pass in quick on $int_wan proto tcp to $int_wan port $wan_port keep state (max 1000, source-track rule, max-src-nodes 500, max-src-states 10)

pass in quick
Означает, что как только это правило сработало для пакета - остальные уже не проверять. Это может сэкономить ресурсы.
on $int_wan proto tcp to $int_wan port $wan_port
Описывается, что все пакеты которые пришли на интерфейс $int_wan по протоколу tcp откуда угодно для ip адреса который присвоен интерфейсу $int_wan на порт $wan_port.
keep-state
Сохранять информацию о состояние соединения. Это тоже помогает сэкономить ресурсы сервера при повторном выполнении этого правила. Замечу, что это можно и не писать, т.к. в данный момент keep state по-умолчанию применяется ко всем правилам.
max 1000
Говорит, о том, что максимальное количество состояний (state) которое может создать это правило - 1000. Если достигнуто это количество, то новые состояния не будут создаваться и новые пакеты не будут соответствовать этому правилу.
source-track rule
Максимальное количество записей состояний созданных правилом ограничивается опциями max-src-nodes и max-src-states. Т.е. подсчет состояний идет локально для правила. Можно написать source-track global - ограничение количества записей созданных всеми правилами, которые используют эту опцию и подсчет состояний будет вестись глобально для всех правил.
max-src-nodes 500
Когда используется опция source-track, опция max-src-nodes ограничивает количество исходных IP адресов, которые могут одновременно создать соединение. Эта опция может быть использована только с опцией source-track rule. Не относится к защите от нашей атаки, но эта опция весьма полезна.
max-src-states 10
Когда используется опция source-track, опция max-src-states ограничивает количество одновременно созданных соединений с одного исходного IP адреса. Это и есть нужная нам опция для защиты. Слишком малое число тоже не стоит ставить, т.к. клиенты часто создают несколько соединений для быстрой работы.
Безусловно, требуется вручную подобрать значения соответствующие задачам Вашего сервера и его ресурсами. Кроме этого можно дополнительно "оттюнинговать" различными timeout`ами и дополнительными правилами, которые могут запоминать атакующих и блокировать их, но эта тема отдельного разговора.

P.S. Статья написана для FreeBSD и PF.

Настройка nginx
rubuntu
О настройке nginx уже много чего сказано, здесь напишу как можно более кратко.
Установим nginx как front-end, а back-end у нас будет apache - достаточно классическая связка.
1. Добавим в rc.conf
nginx_enable="YES"
2. Сконфигурируем apache чтобы он слушал только порт 9999 (например).
Для этого в httpd.conf найдем строчку Listen 12.34.56.78:80 и исправим на Listen 12.34.56.78:9999 или же просто Listen 9999. Если apache и nginx запускаются на одной машине, лучше потом сделать, чтобы apache висел на 127.0.0.1. Если есть виртулхосты, то сменим порт 80 на 9999.
Перезапустим apache "apchectl restart". Проверим, что все работает, зайдем на http://12.34.56.78:9999/
3. Теперь настроим nginx.
Откроем nginx.conf и в директиве server напишем:
поддирективе location / {
  root   /usr/local/www/nginx;
 index  index.html index.htm;
 proxy_pass http://127.0.0.1:9999;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_intercept_errors off;
 proxy_read_timeout 5s;
 proxy_send_timeout 3s;
}
создадим еще один location
location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ {
  root /usr/local/www/apache22/data;
}
Запустим nginx: "rc.d/nginx start"
Теперь все должно работать намного быстрее.
Это все можно дальше оттюнинговать, для получения более высоких результатов производительности.

postfix и open relay
rubuntu
По-умолчанию postfix является open relay. Это означает, что любой может отправить письмо через Ваш сервер. Если вы сделаете это с сервером который подключен к сети интернет, то через достаточно быстро начнут отправлять письма спамеры. При этом информация, о том, что на Вашем сервере включен open relay быстро разлетится среди спамеров и Вашему серверу будет обеспечен шквал писем, которые он будет отправлять. Довольно быстро вы попадете в blacklist`ы и начнутся проблемы с отправкой писем.
Тем не менее это случается достаточно часто, когда Вы пытаетесь настроить postfix в первый раз.
Для того чтобы этого не случилось, можно сделать несколько действий.
В postfix есть опция smtpd_recipient_restrictions, в которой можно задать ограничения при соединении других почтовых клиентов с Вашим почтовым сервером. Ограничения задаются через запятую. Наиболее часто можно встретить такие ограничения:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_auth_destination, reject
где:
permit_sasl_authenticated - разрешать отправлять только пользователям прошедшим аутентификацию;
permit_auth_destination - разрешать отправлять на заданные пункты назначения почты, подробнее;
reject - запретить.

Электроэнергетика в РФ
rubuntu
О чем этот пост?
Хочу Вам рассказать без цифр и кратко о том как работает энергосистема в РФ. Почему кратко? Потому что полно - это тема целой книги, что не могу себе позволить.
Все знают что в нашей стране основные источники энергии это АЭС, ГЭС и ТЭС (ТЭЦ).  Остальные, а это газовые, ветряные, дизельные, солнечные, дают сравнительно не много энергии. Хотя в последнее время с газовые электростанции (ЭС) становятся более популярными.
Кроме этого существуют проблемы, основные проблемы можно сформулировать так: "Производится не достаточное количество электроэнергии, а то что производится не удается передать в полном объеме". Поэтому этот пост будет написан с точки зрения этих двух проблем.
Регулируемые электростанции.
Все электростанции делятся на регулируемые и нерегулируемые.
Зачем это нужно? В дневное время, когда работают предприятия потребление энергии возрастает, а когда ночь, то соответственно падает. Для того чтобы давать необходимое количество энергии надо регулировать выработку энергии.
К регулируемым относится ГЭС. Надо много энергии — открыли клапан, вода стала вращать лопасти турбины, турбина стала вырабатывать электричество. не надо энергия — закрыли клапан.
К нерегулируемым относится АЭС. Если надо много энергии, то поднимают графитовые стержни, но это делается медленно и мощность растет тоже медленно, к тому же это часто делать опасно. Поэтому АЭС являются нерегулируемыми.
ТЭС является слабо регулируемой. Если надо больше мощности, что сжигают больше угля. Но эта регулировка происходит медленней, чем в ГЭС.
Т.е. в то время когда электроэнергия нужна, регулируемые ЭС начинают давать больше энергии, а в то время когда не нужно соответственно меньше.
Проблема.
Дело в том, что АЭС вырабатывают все время почти одинаковое количество электричества и это львиная доля вырабатываемой энергии. Что делать с этим электричеством? Просто вырабатывать в никуда — нельзя, ее надо расходовать, но энергии так много, что можно кипятить озера. Поэтому ее стараются передать туда где она нужна. Например когда в центральном регионе ночь, в дальневосточном уже день и можно передать туда. Путь с невероятными потерями, но девать ее все равно некуда. Здесь и проявляется еще одна проблема, связанная с тем, что не всю энергию можно передать по существующим линиям. Куда же ее девать? Для этого существует еще одно деление ЭС. (кратко, подробно)
Аккумулируемые электростанции.
Некоторые ГЭС умеют накапливать электроэнергию, называются они ГАЭС. Делают это они следующим образом. Когда требуется накопить энергию внизу по течению включаются мощные насосы, которые перекачивает воду вверх по течению, например в специальный резервуар, а как правило просто в бассейн плотины. Уровень воды повышается — следовательно повышается емкость ГАЭС. В больших объемах накапливать энергию могут только ГАЭС и поэтому они так важны для энергосистемы.
Эти проблемы показывают почему нельзя построить в стране только АЭС, хотя они и являются очень перспективными, но не смогут работать без аккумулируемых ГАЭС.
Приветствуются комментарии и исправления.