Архив метки: unix

Объединение двух сетей с одинаковой адресацией через интернет

Объединить две сети через интернет довольно легко. Создаем site-to-site vpn удобным нам способом и пользуемся. А если надо объединить две сети, в которых совпадают диапазоны используемых адресов? Например, две сети с адресацией 192.168.0.0/24. Поначалу может показаться, что идея глупая и это никому не надо. Но есть для этого и практическое применение — обеспечение бесперебойной работы инфраструктуры офиса на время переезда в другое место.

Одним из первых требований, естественно, будет отсутствие совпадающих IP-адресов — в итоге получится одна виртуальная сеть, в которой никто и догадываться не будет, что она разнесена физически на далекие расстояния. Единственным признаком будет увеличение задержек при доступе к «удаленной» части. Впрочем, это требование при сценарии переезда выполнить легко: одинаковых адресов в сети не было и в процессе переезда им неоткуда взяться.

Второе требование — достаточно широкий интернет-канал с низкими задержками. Желательно все это выполнить в пределах одного интернет-провайдера.

И, естественно, третьим требованием будет 2 сервера/компьютера с двумя нормальными сетевыми картами в каждом.

Если все требования выполнены, можно приступать к установке Debian. Именно на этой платформе мы будем реализовывать виртуальный свитч. Описывать установку debian бессмысленно, мануалов в сети предостаточно, да и визард вполне понятен.

После установки debian, ставим пакеты bridge-utils и tinc. Создаем директории /etc/tinc/mynetwork и /etc/tinc/mynetwork/hosts, где mynetwork — имя вашего соединения. В директории /etc/tinc/mynetwork создаем конфигурационный файл tinc.conf и вписываем туда следующие параметры:

Name = segment1
Mode = switch
ConnectTo = segment2

На втором, соответственно:

Name = segment2
Mode = switch
ConnectTo = segment1

В таком режиме, как можно догадаться, tinc будет работать как обычный свитч: пересылаться будут только те пакеты, которые направлены к хостам в другом сегменте. Для этого tinc будет регулярно рассылать ARP-запросы и поддерживать в актуальном состоянии таблицу MAC-адресов. Если же нужна пересылка абсолютно всего трафика — можно воспользоваться режимом «hub», что собственно и соответствует логике работы обычного хаба.

После того, как созданы конфигурационные файлы, надо сгенерировать ключи для установки защищенного соединения. Для этого выполняем команду:

tincd -n mynetwork -K

Эта команда генерирует private key и public key и сохраняет их в указанном месте (по умолчанию, в директории /etc/tinc/mynetwork хранится private key, а в директории /etc/tinc/mynetwork/hosts — public key. Имя публичного ключа совпадает с именем, заданным в tinc.conf параметром Name. Редактируем файл с публичным ключом и вписываем в первой строке (до начала —— BEGIN RSA PUBLIC KEY):

Address = 1.2.3.4

, где 1.2.3.4 — внешний адрес этого хоста. После этого копируем файлы из директории /etc/tinc/mynetwork/hosts с одного хоста на другой.

В директории /etc/tinc/mynetwork создаем скрипт tinc-up с содержимым:

#!/bin/sh

ifconfig $INTERFACE 0.0.0.0
brctl addif bridge $INTERFACE
ifconfig $INTERFACE up

Этот скрипт будет запускаться при старте демона tincd. Для автоматической установки соединения при старте системы, необходимо вписать имя сети (mynetwork) в файл /etc/tinc/nets.boot.

И, наконец, последнее, что необходимо сделать для того, чтобы все работало — создать, собственно, мост и сделать так, чтобы при старте системы он создавался автоматически. Для этого создаем скрипт /etc/tinc/createbridge со следующим содержимым:

#!/bin/sh

brctl addbr bridge
ifconfig bridge 192.168.0.2 netmask 255.255.255.0
ifconfig eth1 0.0.0.0
brctl addif bridge eth1
ifconfig eth1 up

, где 192.168.0.2 — адрес хоста в сети, а eth1 — интерфейс, к которому подключена локальная сеть. Делаем скрипт исполняемым и добавляем в /etc/network/interfaces в параметры интерфейса eth1 строку:

post-up /etc/tinc/createbridge

Перезагружаем оба сервера и проверяем наличие соединения между хостами. Если соединение не установлено — смотрим логи и проверяем наличие интернета. Если не помогло — читаем мануал :)

Тюнинг MySQL в ISPmanager 4. Не сохраняются изменения.

Довелось мне недавно столкнуться с панелью ISPManager 4, установленной на CentOS 6.5. Это был довольно слабый сервер на десктопном железе, но при этом количество сайтов на нем переваливало за сотню. Всего лишь 2 SATA-винчестера по 500 Гб в зеркале и 32 Гб SSD для баз mysql. Оперативной памяти было всего-то 8 Гб, но этого должно быть достаточно для работы сервера при грамотной настройке. А вот с грамотной настройкой были проблемы и по этой причине Load Average скакал от 4 до 60. В общем-то, 4 — это нормальная цифра для 4-ядерного процессора, но 60…

Первое, за что я решил взяться — это тюнинг MySQL. Открыл рабочий конфиг и взялся за голову: это был дефолтный конфиг из типовых настроек для «маленького» сервера, т.е. my-small.cnf:

# Example MySQL config file for small systems.
#
# This is for a system with little memory (<= 64M) where MySQL is only used
# from time to time and it's important that the mysqld daemon
# doesn't use much resources.
#
# MySQL programs look for option files in a set of
# locations which depend on the deployment platform.
# You can copy this option file to one of those
# locations. For information about these locations, see:
# http://dev.mysql.com/doc/mysql/en/option-files.html
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 128K

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (using the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
server-id = 1

# Uncomment the following if you want to log updates
#log-bin=mysql-bin

# binary logging format - mixed recommended
#binlog_format=mixed

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M

[mysqlhotcopy]
interactive-timeout

Как видим из конфига, ничего хорошего с таким сервером при >100 сайтов просто не могло быть: все кэши минимальные, кэш запросов не указан, а значит выключен, thread_cache_size не установлен, а значит равен нулю и т.д. Помимо этого, лимит открытых файлов на сервере равнялся 1024. Первым делом поднят был именно он (до 80000), после этого были подкручены table_open_cache, query_cache_size, thread_cache_size и некоторое количество других буферов. Настало время перезапуска сервера для применения настроек. Перезапуск производился средствами панели и каково же было мое удивление, когда вместо своего конфига я опять увидел дефолтный!

Как водится, поиск в гугле на тему подмены конфига ничего не дал. Беглый осмотр вики производителя панели выдал только информацию по добавлению mysql-сервера в панель. Пришлось покопаться в самой панели и внезапно обнаружить, что при рестарте mysql-сервера, происходит копирование все того же my-small.cnf в my.cnf! Оставим вопросы о целесообразности такого решения разработчикам: есть у меня стойкое ощущение, что многие владельцы (язык не поворачивается называть этих людей администраторами) этих панелей не знают что такое ssh и для чего он вообще нужен, если все есть в панели.

Таким образом, одним из возможных решений этой проблемы, является внесение изменений в my-small.cnf (в центоси он лежит тут: /usr/share/mysql), который и будет скопирован в /etc/my.cnf.

А как же советы по настройке? Настройка параметров — дело индивидуальное и сильно зависит от самого сервера, количества сайтов, количества Innodb и myisam таблиц и т.д.