Оказалось, штатно нет OpenID библиотек для перла. Нашлось оно в RPMForge
"RPMforge является результатом сотрудничества Dag-а,Dries-а, и других создателей пакетов. Он обеспечивает более 4000 пакетов для CentOS, в том числе MPlayer, XMMS-mp3 и другие популярные медиа программы." отсюда
Ставим RPMForge
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
Для CentOS5
rpm -ivh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.`uname -i`.rpm
Почему-то так не прошло, ругалось на непонятную ошибку. Делаем тогда примерно по офдоке:
wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.`uname -i`.rpm; rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm && rpm -i rpmforge-release-0.5.1-1.el5.rf.*.rpm
Для CentOS6 заменяем el5 на el6
После этого появляется пакет
perl-Net-OpenID-Server.noarch
Впрочем, надо ещё Net::OpenID::Consumer, который в rpmforge есть только под 6 центось.
Вообще, он есть тут: http://packages.sw.be/perl-Net-OpenID-Consumer/
Но при попытке скачать получаем not found...
среда, 30 марта 2011 г.
вторник, 29 марта 2011 г.
NFS: учимся монтировать
[черновик]
Большая дока
http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html
Основной файл с тем, что экспортируем - /etc/exports
А вот то, что там пишется, в centos и freebsd отличается.
Пример задачи: монтируем /mnt, с возможностью монтировать любую папку оттуда, на запись
Есть ещё проблема - 3 и 4 версии весьма отличаются, демонами, параметрами итд.
FreeBSD:
/mnt -maproot=0 -alldirs
CentOS:
/mnt 192.168.2.0/24(rw,no_root_squash)
Про solaris: http://solarisblog.ru/networks/osnovy-nfs-v-os-solaris
Варианты монтирования клиентом:
вручную через mount -t nfs
через fstab
через automount
Оптимизация
rsize - "буфер чтения", число байт для чтения файла от сервера. На стадии установления соединения выясняется максимальный размер этого буфера. Чем больше, тем быстрее работа NFS, но в случае сбоя и больше времени на восстановление. На плохом канале большой буфер может сделать соединение нерабочим. В локалке можно выставить 32768
wsize - "буфер записи". См выше.
Выставляется в лине и фре по разному.
linux: rsize=16384,wsize=16384
freebsd: -w=32768,-r=32768
Более того, вывод будет отличаться:
linux: (rw,rsize=16384,wsize=16384,addr=192.168.2.15)
freebsd: (nfs, asynchronous, noatime)
Опции немного разные, но главное - в лине прописаны эти буферы, а во фре -- нет.
Монтирование на клиенте.
1) fstab
Стандартная строка выгляжит так:
server:/url /local/url nfs defaults 0 0
Дополнительные ключи
Размеры буфера чтения и записи.
freebsd: (rw|ro),(tcp|udp),(intr|nointr),(hard|soft),noatime,(nfsv3|nfsv4),(bg|fg),-w=32768,-r=32768,timeo=300
Есть (не)маленький шанс поймать в messages ошибки
kernel: lockd: server nfs-server not responding, timed out
last message repeated 15 times
В частности, у меня была такая ошибка при линковке линя к фря-серверу. Думаю, надо тюнить систему, но не совсем понятно, куда. Или это просто баг?
В общем, использование tcp даже в локалке обязательно. Сильно повышает стабильность. А на гигабите udp может быть и опасен.
Большая дока
http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html
Основной файл с тем, что экспортируем - /etc/exports
А вот то, что там пишется, в centos и freebsd отличается.
Пример задачи: монтируем /mnt, с возможностью монтировать любую папку оттуда, на запись
Есть ещё проблема - 3 и 4 версии весьма отличаются, демонами, параметрами итд.
FreeBSD:
/mnt -maproot=0 -alldirs
CentOS:
/mnt 192.168.2.0/24(rw,no_root_squash)
Про solaris: http://solarisblog.ru/networks/osnovy-nfs-v-os-solaris
Варианты монтирования клиентом:
вручную через mount -t nfs
через fstab
через automount
Оптимизация
rsize - "буфер чтения", число байт для чтения файла от сервера. На стадии установления соединения выясняется максимальный размер этого буфера. Чем больше, тем быстрее работа NFS, но в случае сбоя и больше времени на восстановление. На плохом канале большой буфер может сделать соединение нерабочим. В локалке можно выставить 32768
wsize - "буфер записи". См выше.
Выставляется в лине и фре по разному.
linux: rsize=16384,wsize=16384
freebsd: -w=32768,-r=32768
Более того, вывод будет отличаться:
linux: (rw,rsize=16384,wsize=16384,addr=192.168.2.15)
freebsd: (nfs, asynchronous, noatime)
Опции немного разные, но главное - в лине прописаны эти буферы, а во фре -- нет.
Монтирование на клиенте.
1) fstab
Стандартная строка выгляжит так:
server:/url /local/url nfs defaults 0 0
Дополнительные ключи
Размеры буфера чтения и записи.
freebsd: (rw|ro),(tcp|udp),(intr|nointr),(hard|soft),noatime,(nfsv3|nfsv4),(bg|fg),-w=32768,-r=32768,timeo=300
Есть (не)маленький шанс поймать в messages ошибки
kernel: lockd: server nfs-server not responding, timed out
last message repeated 15 times
В частности, у меня была такая ошибка при линковке линя к фря-серверу. Думаю, надо тюнить систему, но не совсем понятно, куда. Или это просто баг?
В общем, использование tcp даже в локалке обязательно. Сильно повышает стабильность. А на гигабите udp может быть и опасен.
понедельник, 28 марта 2011 г.
Редирект с http на https
Через .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
отсюда
В комментах тоже много интересного.
ещё
и даже такое...
На PHP
function redirectToHTTPS() {
if($_SERVER['HTTPS']!=="on") {
$redirect= "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
header("Location:$redirect");
}
}
Nginx
Прописываем в нужный server код:
location / {
rewrite ^/(.*) https://$host/$1 permanent;
}
Это не проверял. В теории должно работать. (вариант: https://$host$1 permanent).
!!! Для новых версий предпочтительно использовать новую конструкцию:
return 301 https://freebsd.ru$request_uri;
Вообще, для nginx правильнее определить отдельный конфиг для таких редиректов (опция server_name максимально соответствует нужному домену, прописан listen под нужный порт, и весь конфиг - сам server_name и return 301, этот вариант самый быстрый)
perl
$q = new CGI;
print $q->redirect(“http://www.new-url.com/”);
Линки
http://nginx.org/en/docs/http/converting_rewrite_rules.html
http://wiki.nginx.org/IfIsEvil
http://devaka.ru/articles/redirect-301
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
отсюда
В комментах тоже много интересного.
ещё
и даже такое...
На PHP
function redirectToHTTPS() {
if($_SERVER['HTTPS']!=="on") {
$redirect= "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
header("Location:$redirect");
}
}
Nginx
Прописываем в нужный server код:
location / {
rewrite ^/(.*) https://$host/$1 permanent;
}
Это не проверял. В теории должно работать. (вариант: https://$host$1 permanent).
!!! Для новых версий предпочтительно использовать новую конструкцию:
return 301 https://freebsd.ru$request_uri;
Вообще, для nginx правильнее определить отдельный конфиг для таких редиректов (опция server_name максимально соответствует нужному домену, прописан listen под нужный порт, и весь конфиг - сам server_name и return 301, этот вариант самый быстрый)
perl
$q = new CGI;
print $q->redirect(“http://www.new-url.com/”);
Линки
http://nginx.org/en/docs/http/converting_rewrite_rules.html
http://wiki.nginx.org/IfIsEvil
http://devaka.ru/articles/redirect-301
четверг, 24 марта 2011 г.
среда, 23 марта 2011 г.
Ещё о репликации
Есть сервер, надо поднять ему slave.
Раньше была команда load data from master, но потом её объявили deprecated. Сейчас 2 метода:
1) rsync/csync2/etc
2) dump - restore
Оба сервера должны быть предварительно подготовлены -- создан юзер для репликации, прописаны server-id, bin-log итд.
На слейве - прописаны базы/таблицы для репликации.
Если сихронизировать через rsync, базы на слейве надо предварительно создать, причём крайне желательно, чтобы такие параметры как язык совпадал. Движок (engine) совпадать должен обязательно! И так не получится перенести innodb. Для dump можно указать ключ
Пользователи и права переносятся руками.
Любые такие операции выполняются с flush tables with read lock, show master status
По идее, можно остановить мастер, выполнить файловую синхронизацию.. но как в этом случае узнать позицию в логе? А без неё не запустить репликацию, так что получили п.1
1) сихронизируем (пока без остановки - главное, перегнать основной объем);
flush, show, делаем синхронизацию, снова show чтобы проверить, что ничего не убежало, снимаем лок (unlock tables), меняем мастера.
Но тут обнаружилась проблема: первая синхронизация шла со скоростью порядка 10мбит/с (канал такой, но проектам хватает), а вот вторая...
sent 2751559 bytes received 2278456 bytes 3617.41 bytes/sec
3кб/с! Заняло это минут 20, что вызвало 500 ошибку. А изменений было относительно немного... Вывод - этот метод непригоден для нагруженных проектов, с часто изменяемыми данными. Да и просто большими базами. Но хорошо работает на копировании с slave-сервера, подробнее есть ниже (с остановкой sql_thread и переносом файлов). И только для myisam; innodb в режиме разделения по файлам.
2) dump
могут пригодиться ключи
--master-data - обязательный ключ. Включает в себя CHANGE MASTER TO - устанавливает позицию в логе итд. Можно дописать =1 или 2: при 1 CHANGE MASTER TO сменит мастера и позицию, при 2 CHANGE MASTER TO закомментирован и несёт скорее информативный характер.
--delete-master-logs - имеет смысл только если слейв 1 или для бэкапов.
--single-transaction - в 1 поток, это несколько быстрее, но ставит глобальный лок на некоторое время. Имеет смысл только с транзакционными движками типа InnoDB
--create-db - создать базу
--opt - ключ, который включает в себя массу других, наиболее часто применямых. Рекомендуемо. Впрочем, если верить ману, он включен по умолчанию.
Важный момент: если надо перенести больше 1 базы - позиция должна быть неизменной или для каждой заливки надо делать flush, dump, restore, иначе данные могут оказаться разными на разных серверах.
В man mysqldump описан ещё вариант создания слейва, если уже есть хотя бы один, искать описание --master-data
Приведу тут пересказ:
1. Остановить SQL поток на слейве
mysql> STOP SLAVE SQL_THREAD;
mysql> SHOW SLAVE STATUS;
Нужны поля Relay_Master_Log_File и Exec_Master_Log_Pos
2. Дампим данные
shell> mysqldump --master-data=2 --all-databases > dumpfile
3. запускаем слейв
mysql> START SLAVE;
4. На новом слейве загружаем дамп
shell> mysql < dumpfile 5. На новом слейве меняем мастера mysql> CHANGE MASTER TO
-> MASTER_LOG_FILE = 'file_name', MASTER_LOG_POS = file_pos;
Может потребоваться также задать такие значения как MASTER_HOST
Ещё момент - при использовании ZFS можно сделать lock, дождаться его (как?), сделать snapshot, получить master_pos, unlock. И теперь можно перекидывать данные или сам снапшот на другой сервер (если делаем полную копию)
12.5.2.1. CHANGE MASTER TO Syntax
CHANGE MASTER TO option [, option] ...
option:
MASTER_HOST = 'host_name'
| MASTER_USER = 'user_name'
| MASTER_PASSWORD = 'password'
| MASTER_PORT = port_num
| MASTER_CONNECT_RETRY = interval
| MASTER_LOG_FILE = 'master_log_name'
| MASTER_LOG_POS = master_log_pos
| RELAY_LOG_FILE = 'relay_log_name'
| RELAY_LOG_POS = relay_log_pos
| MASTER_SSL = {0|1}
| MASTER_SSL_CA = 'ca_file_name'
| MASTER_SSL_CAPATH = 'ca_directory_name'
| MASTER_SSL_CERT = 'cert_file_name'
| MASTER_SSL_KEY = 'key_file_name'
| MASTER_SSL_CIPHER = 'cipher_list'
http://dev.mysql.com/doc/refman/5.0/en/change-master-to.html
--размышления--
Вот есть у нас сервер, к примеру с десятком баз, реплицируется допустим 8. Как переносить базы на другой сервер, с минимальным простоем? Если делать к примеру mysqldump на каждую базу, то master-data будет показывать на разные записи. Что будет происходить при загрузке этих дампов? Как обеспечить тогда синхронность данных? Делать после каждой заливки slave start,...,slave stop и следующую заливать? Залить просто все, потом на slave start оно само выровняет? Сомневаюсь.
Обидно, что нет команды resync например, чтобы сервер сам проверил все записи и нужные слил. Важно, чтобы еще с innodb работало. С инной даже проще - делаем транзакцию (и получаем целостный набор данных), и сохраняем в переменные текущую лог-позицию. После синхронизации завершаем транзакцию и выставляем лог. Причем для оперативности можно relay-log с текущей позиции сразу вести, и по окончанию перелива быстро прогнать его.
Раньше была команда load data from master, но потом её объявили deprecated. Сейчас 2 метода:
1) rsync/csync2/etc
2) dump - restore
Оба сервера должны быть предварительно подготовлены -- создан юзер для репликации, прописаны server-id, bin-log итд.
На слейве - прописаны базы/таблицы для репликации.
Если сихронизировать через rsync, базы на слейве надо предварительно создать, причём крайне желательно, чтобы такие параметры как язык совпадал. Движок (engine) совпадать должен обязательно! И так не получится перенести innodb. Для dump можно указать ключ
Пользователи и права переносятся руками.
Любые такие операции выполняются с flush tables with read lock, show master status
По идее, можно остановить мастер, выполнить файловую синхронизацию.. но как в этом случае узнать позицию в логе? А без неё не запустить репликацию, так что получили п.1
1) сихронизируем (пока без остановки - главное, перегнать основной объем);
flush, show, делаем синхронизацию, снова show чтобы проверить, что ничего не убежало, снимаем лок (unlock tables), меняем мастера.
Но тут обнаружилась проблема: первая синхронизация шла со скоростью порядка 10мбит/с (канал такой, но проектам хватает), а вот вторая...
sent 2751559 bytes received 2278456 bytes 3617.41 bytes/sec
3кб/с! Заняло это минут 20, что вызвало 500 ошибку. А изменений было относительно немного... Вывод - этот метод непригоден для нагруженных проектов, с часто изменяемыми данными. Да и просто большими базами. Но хорошо работает на копировании с slave-сервера, подробнее есть ниже (с остановкой sql_thread и переносом файлов). И только для myisam; innodb в режиме разделения по файлам.
2) dump
могут пригодиться ключи
--master-data - обязательный ключ. Включает в себя CHANGE MASTER TO - устанавливает позицию в логе итд. Можно дописать =1 или 2: при 1 CHANGE MASTER TO сменит мастера и позицию, при 2 CHANGE MASTER TO закомментирован и несёт скорее информативный характер.
--delete-master-logs - имеет смысл только если слейв 1 или для бэкапов.
--single-transaction - в 1 поток, это несколько быстрее, но ставит глобальный лок на некоторое время. Имеет смысл только с транзакционными движками типа InnoDB
--create-db - создать базу
--opt - ключ, который включает в себя массу других, наиболее часто применямых. Рекомендуемо. Впрочем, если верить ману, он включен по умолчанию.
Важный момент: если надо перенести больше 1 базы - позиция должна быть неизменной или для каждой заливки надо делать flush, dump, restore, иначе данные могут оказаться разными на разных серверах.
В man mysqldump описан ещё вариант создания слейва, если уже есть хотя бы один, искать описание --master-data
Приведу тут пересказ:
1. Остановить SQL поток на слейве
mysql> STOP SLAVE SQL_THREAD;
mysql> SHOW SLAVE STATUS;
Нужны поля Relay_Master_Log_File и Exec_Master_Log_Pos
2. Дампим данные
shell> mysqldump --master-data=2 --all-databases > dumpfile
3. запускаем слейв
mysql> START SLAVE;
4. На новом слейве загружаем дамп
shell> mysql < dumpfile 5. На новом слейве меняем мастера mysql> CHANGE MASTER TO
-> MASTER_LOG_FILE = 'file_name', MASTER_LOG_POS = file_pos;
Может потребоваться также задать такие значения как MASTER_HOST
Ещё момент - при использовании ZFS можно сделать lock, дождаться его (как?), сделать snapshot, получить master_pos, unlock. И теперь можно перекидывать данные или сам снапшот на другой сервер (если делаем полную копию)
12.5.2.1. CHANGE MASTER TO Syntax
CHANGE MASTER TO option [, option] ...
option:
MASTER_HOST = 'host_name'
| MASTER_USER = 'user_name'
| MASTER_PASSWORD = 'password'
| MASTER_PORT = port_num
| MASTER_CONNECT_RETRY = interval
| MASTER_LOG_FILE = 'master_log_name'
| MASTER_LOG_POS = master_log_pos
| RELAY_LOG_FILE = 'relay_log_name'
| RELAY_LOG_POS = relay_log_pos
| MASTER_SSL = {0|1}
| MASTER_SSL_CA = 'ca_file_name'
| MASTER_SSL_CAPATH = 'ca_directory_name'
| MASTER_SSL_CERT = 'cert_file_name'
| MASTER_SSL_KEY = 'key_file_name'
| MASTER_SSL_CIPHER = 'cipher_list'
http://dev.mysql.com/doc/refman/5.0/en/change-master-to.html
--размышления--
Вот есть у нас сервер, к примеру с десятком баз, реплицируется допустим 8. Как переносить базы на другой сервер, с минимальным простоем? Если делать к примеру mysqldump на каждую базу, то master-data будет показывать на разные записи. Что будет происходить при загрузке этих дампов? Как обеспечить тогда синхронность данных? Делать после каждой заливки slave start,...,slave stop и следующую заливать? Залить просто все, потом на slave start оно само выровняет? Сомневаюсь.
Обидно, что нет команды resync например, чтобы сервер сам проверил все записи и нужные слил. Важно, чтобы еще с innodb работало. С инной даже проще - делаем транзакцию (и получаем целостный набор данных), и сохраняем в переменные текущую лог-позицию. После синхронизации завершаем транзакцию и выставляем лог. Причем для оперативности можно relay-log с текущей позиции сразу вести, и по окончанию перелива быстро прогнать его.
вторник, 22 марта 2011 г.
Цинизм в IT: Феерически о Node.js
Цинизм в IT: Феерически о Node.js: "Это серверный однопоточный джаваскрипт-движок на событиях (libev), состоящий из гугловского якобы высокопроизводительного JIT-компилятора V8 и библиотеки асинхронного ввода-вывода к нему...."
понедельник, 21 марта 2011 г.
Centos и 2Tb WD
Купил диск EARS-серии, который "4k sectors". Хороший вариант для бэкапов - тихий, холодный, ёмкий. Заодно пора переходить на GPT в связи с лимитами MBR.
На самом деле, это имеет смысл и для SSD делать -- у них тоже сектор может быть больше.
Вставляем диск, его определило как /dev/sdf
У нас 2 проблемы: Размер сектора должен быть кратен 4кбайтам и надо выравнивать разделы. Винда выравнивает на 1мб, fdisk тоже в последних версиях.
fdisk: Version 0.6.6 introduces a Windows-style 2048-sector (1MB) alignment for all unpartitioned disks and attempts to infer the alignment used in the past on disks with existing partitions.
Также могут быть проблемы с загрузкой с диска, где сектор=4к.
Размечать диск можно несколькими способами:
1) через fdisk, указав размер цилиндров-голов так, чтобы получилась кратность 8
fdisk -H 224 -S 56
2) новые версии fdisk, которые имеют ключи -u -c. Это пакет util-linux-ng, в центоси он util-linux, причем нужна версия 2.18+, тогда как в системе 2.13. Более свежей не нашел, гугль не помог.
3) parted. Поддержка секторов >512 байт появилась только в конце 2010 года, в 2.х ветке. Опять же, в центоси он есть в 6.0, а в 5.5 нету нигде, включая всякие remi-test, epel-testing, c5-testing итд.
4) при форматировании задать размер блока в 4к. Но начало раздела надо выровнять!
mke2fs -j -b 4096 -i 4096 /dev/sdx
# parted /dev/sdf
GNU Parted 1.8.1
Using /dev/sdf
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: Unable to open /dev/sdf - unrecognised disk label.
(parted) help mklabel
mklabel,mktable LABEL-TYPE create a new disklabel (partition table)
LABEL-TYPE is one of: aix, amiga, bsd, dvh, gpt, mac, msdos, sun, loop
Итак, мы видим варианты меток, нам нужен GPT
Но...
(parted) mklabel gpt
(parted) print
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sdf: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Сектора в 4к пока не сделать.
Если попытаться запустить fdisk -l -v, получим
WARNING: GPT (GUID Partition Table) detected on '/dev/sdf'! The util fdisk doesn't support GPT. Use GNU Parted.
Итак.
fdisk -H 224 -S 56 /dev/sdf
u
n, p, 1, 2048,
w
Disk /dev/sdf: 2000.3 GB, 2000398934016 bytes
224 heads, 56 sectors/track, 311465 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdf1 2048 3907029167 1953513560 83 Linux
mke2fs -j -b 4096 -i 4096 /dev/sdf1
Пока сойдёт, но потом всё-таки хочу сделать GPT с норм блоками.
То есть тоже старая версия...
В общем, или облом, или переходим на ветку 6.0. А пока можно через цилиндры при создании разделов делать.
А пока можно почитать Linux Not Fully Prepared for 4096-Byte Sector Hard Drives, Linux on 4KB-sector disks: Practical advice, офсайт
Практическая проверка подобного диска от тошибы
На самом деле, это имеет смысл и для SSD делать -- у них тоже сектор может быть больше.
Вставляем диск, его определило как /dev/sdf
У нас 2 проблемы: Размер сектора должен быть кратен 4кбайтам и надо выравнивать разделы. Винда выравнивает на 1мб, fdisk тоже в последних версиях.
fdisk: Version 0.6.6 introduces a Windows-style 2048-sector (1MB) alignment for all unpartitioned disks and attempts to infer the alignment used in the past on disks with existing partitions.
Также могут быть проблемы с загрузкой с диска, где сектор=4к.
Размечать диск можно несколькими способами:
1) через fdisk, указав размер цилиндров-голов так, чтобы получилась кратность 8
fdisk -H 224 -S 56
2) новые версии fdisk, которые имеют ключи -u -c. Это пакет util-linux-ng, в центоси он util-linux, причем нужна версия 2.18+, тогда как в системе 2.13. Более свежей не нашел, гугль не помог.
3) parted. Поддержка секторов >512 байт появилась только в конце 2010 года, в 2.х ветке. Опять же, в центоси он есть в 6.0, а в 5.5 нету нигде, включая всякие remi-test, epel-testing, c5-testing итд.
4) при форматировании задать размер блока в 4к. Но начало раздела надо выровнять!
mke2fs -j -b 4096 -i 4096 /dev/sdx
# parted /dev/sdf
GNU Parted 1.8.1
Using /dev/sdf
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: Unable to open /dev/sdf - unrecognised disk label.
(parted) help mklabel
mklabel,mktable LABEL-TYPE create a new disklabel (partition table)
LABEL-TYPE is one of: aix, amiga, bsd, dvh, gpt, mac, msdos, sun, loop
Итак, мы видим варианты меток, нам нужен GPT
Но...
(parted) mklabel gpt
(parted) print
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sdf: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Сектора в 4к пока не сделать.
Если попытаться запустить fdisk -l -v, получим
WARNING: GPT (GUID Partition Table) detected on '/dev/sdf'! The util fdisk doesn't support GPT. Use GNU Parted.
Итак.
fdisk -H 224 -S 56 /dev/sdf
u
n, p, 1, 2048,
w
Disk /dev/sdf: 2000.3 GB, 2000398934016 bytes
224 heads, 56 sectors/track, 311465 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdf1 2048 3907029167 1953513560 83 Linux
mke2fs -j -b 4096 -i 4096 /dev/sdf1
Пока сойдёт, но потом всё-таки хочу сделать GPT с норм блоками.
То есть тоже старая версия...
В общем, или облом, или переходим на ветку 6.0. А пока можно через цилиндры при создании разделов делать.
А пока можно почитать Linux Not Fully Prepared for 4096-Byte Sector Hard Drives, Linux on 4KB-sector disks: Practical advice, офсайт
Практическая проверка подобного диска от тошибы
пятница, 18 марта 2011 г.
возня с mdadm
Понадобилось сделать несколько рейдов. В линуксе выбор небольшой: если нет аппаратного рейда, или dm-mapper для fake-raid, или mdadm. LVM тут не поможет никак, а нормальных фс типа zfs тут только btrfs, который пока еще бьет данные и в продакшене недопустим.
Попробуем mdadm как наиболее универсальное. Создадим для начала зеркало на 1 диске, указав второй как отсутствующий - missing
# mdadm --create --level=1 --metadata=1.0 sdb missing
mdadm: sdb does not exist and is not a 'standard' name so it cannot be created
# mdadm --create --level=1 --metadata=1.0 /dev/sdb missing
mdadm: no raid-devices specified.
# mdadm --create --level=1 --metadata=1.0 -n 2 /dev/sdb missing
mdadm: You haven't given enough devices (real or missing) to create this array
Сообщения об ошибке просто поражают точностью (подробно - дальше) и смыслом.
После долгого курения манов оказывается, что ему _обязательно_ указывать имя будущего массива.
# mdadm --create test --level=1 --metadata=1.0 -n 2 /dev/sdb missing
mdadm: test does not exist and is not a 'standard' name so it cannot be created
После дальнейшего гугленья оказалось, что имя _обязано_ быть md*
# mdadm --create md2 --level=1 -n 2 --metadata=1.0 sdb missing
mdadm: md2 does not exist and is not a 'standard' name so it cannot be created
Это имя должно показывать в /dev...
# mdadm --create /dev/md5 --level=1 -n 2 --metadata=1.0 sdb missing
mdadm: Cannot open sdb: No such file or directory
mdadm: create aborted
Опа. Ну ладно, тут тоже хотим полный путь. (сообщения об ошибке гениальные, ага. Писано гуру для гуру)
И сделаю заодно ещё вещь: поскольку имена тут кривые, в мане всё-таки нашлась опция для указания своего имени --name=, причём допустимо только для метадаты 1.0+ версий (штатно 0.9).
# mdadm --create /dev/md5 --level=1 --metadata=1.0 -n 2 --name="1T" /dev/sdb missing
mdadm: /dev/sdb is too small: 0K
mdadm: create aborted
Ему мало диска в 1 терабайт... Шикарно.
Хотя тут может и косяк железа - после передёргивания диска оно заработало.
Мониторить надо через /proc/mdstat - ещё один сюрприз. Впрочем, есть
# mdadm --detail /dev/md5
Добавить второй диск потом можно через
#mdadm /dev/md5 --add /dev/sdd
После создания массива можно (и нужно?) скинуть информацию о массивах в конфиг
# mdadm --detail --scan >> /etc/mdadm.conf
Можно еще первой строкой вписать
DEVICE /dev/hd* /dev/sd*
(отсюда)
Просмотр состояния:
#mdadm --detail /dev/md5
#cat /proc/mdstat
В стате есть информация о перестройке массива, например процент выполнения, состояние дисков, ожидаемое время перестроения, скорость.
Можно настроить алерты.
# mdadm --monitor --scan --mail=you@domain.com delay=3600 --daemonise /dev/md0 /dev/md1
Этот момент нашел в гугле - долгое чтение мана про это просветления не дало, тут
К слову, статья большая и применима ко многим системам, только начало пропустить.
Несколько замечаний.
Многие советуют создавать раздел не на весь диск, а создав раздел и уже поверх него. Для дисков только с данными смысл есть, а вот для системных не так очевидно - установив новый загрузчик или изменив старый, надо для каждого из дисков выполнить обновление. В случае целого диска - рейд сам отзеркалит данные.
Если используется рейд, отличный от 1, надо убедиться, что в ядре есть драйвер для нужного уровня рейда, иначе получим "кусок тут, кусок там", системе непонятно, как грузиться, и больше она не загрузится. Особенно актуально для 5-6 уровней. Или /boot в начале каждого диска.. с ручной синхронизацией загрузчиков, в том числе после замены диска.
1.0+ метаинформация: 1.0 - в конце диска, 1.1 - в начале, 1.2 - начало+4к. Видимо, для совместимости с загрузчиком.
Ели надо перенести куда-то массив - у вас проблемы. Просто вынуть диски тут, вставить там - можно получить что угодно вплоть до потери данных. Хоть и есть mdadm --scan
Заменить диск, судя по всему, тоже задача нетривиальная, по ссылке выше - требуется использовать fdisk и править разделы. Это не аппаратный массив с "вынул старый - вставил новый", и не gmirror c gmirror forget;gmirror insert ...
Совсем непонятно, как сделать рейд из одиночного диска без его форматирования, причем чтобы метаинформация сохранялась.
UPD: Перенос Centos Linux 5 с одного диска на Soft Raid
Моя ошибка была в том, что я начал с манов, а надо было начинать отсюда:
Вики (рус) - там тоже есть инфа по работе с массивом.
Попробуем mdadm как наиболее универсальное. Создадим для начала зеркало на 1 диске, указав второй как отсутствующий - missing
# mdadm --create --level=1 --metadata=1.0 sdb missing
mdadm: sdb does not exist and is not a 'standard' name so it cannot be created
# mdadm --create --level=1 --metadata=1.0 /dev/sdb missing
mdadm: no raid-devices specified.
# mdadm --create --level=1 --metadata=1.0 -n 2 /dev/sdb missing
mdadm: You haven't given enough devices (real or missing) to create this array
Сообщения об ошибке просто поражают точностью (подробно - дальше) и смыслом.
После долгого курения манов оказывается, что ему _обязательно_ указывать имя будущего массива.
# mdadm --create test --level=1 --metadata=1.0 -n 2 /dev/sdb missing
mdadm: test does not exist and is not a 'standard' name so it cannot be created
После дальнейшего гугленья оказалось, что имя _обязано_ быть md*
# mdadm --create md2 --level=1 -n 2 --metadata=1.0 sdb missing
mdadm: md2 does not exist and is not a 'standard' name so it cannot be created
Это имя должно показывать в /dev...
# mdadm --create /dev/md5 --level=1 -n 2 --metadata=1.0 sdb missing
mdadm: Cannot open sdb: No such file or directory
mdadm: create aborted
Опа. Ну ладно, тут тоже хотим полный путь. (сообщения об ошибке гениальные, ага. Писано гуру для гуру)
И сделаю заодно ещё вещь: поскольку имена тут кривые, в мане всё-таки нашлась опция для указания своего имени --name=, причём допустимо только для метадаты 1.0+ версий (штатно 0.9).
# mdadm --create /dev/md5 --level=1 --metadata=1.0 -n 2 --name="1T" /dev/sdb missing
mdadm: /dev/sdb is too small: 0K
mdadm: create aborted
Ему мало диска в 1 терабайт... Шикарно.
Хотя тут может и косяк железа - после передёргивания диска оно заработало.
Мониторить надо через /proc/mdstat - ещё один сюрприз. Впрочем, есть
# mdadm --detail /dev/md5
Добавить второй диск потом можно через
#mdadm /dev/md5 --add /dev/sdd
После создания массива можно (и нужно?) скинуть информацию о массивах в конфиг
# mdadm --detail --scan >> /etc/mdadm.conf
Можно еще первой строкой вписать
DEVICE /dev/hd* /dev/sd*
(отсюда)
Просмотр состояния:
#mdadm --detail /dev/md5
#cat /proc/mdstat
В стате есть информация о перестройке массива, например процент выполнения, состояние дисков, ожидаемое время перестроения, скорость.
Можно настроить алерты.
# mdadm --monitor --scan --mail=you@domain.com delay=3600 --daemonise /dev/md0 /dev/md1
Этот момент нашел в гугле - долгое чтение мана про это просветления не дало, тут
К слову, статья большая и применима ко многим системам, только начало пропустить.
Несколько замечаний.
Многие советуют создавать раздел не на весь диск, а создав раздел и уже поверх него. Для дисков только с данными смысл есть, а вот для системных не так очевидно - установив новый загрузчик или изменив старый, надо для каждого из дисков выполнить обновление. В случае целого диска - рейд сам отзеркалит данные.
Если используется рейд, отличный от 1, надо убедиться, что в ядре есть драйвер для нужного уровня рейда, иначе получим "кусок тут, кусок там", системе непонятно, как грузиться, и больше она не загрузится. Особенно актуально для 5-6 уровней. Или /boot в начале каждого диска.. с ручной синхронизацией загрузчиков, в том числе после замены диска.
1.0+ метаинформация: 1.0 - в конце диска, 1.1 - в начале, 1.2 - начало+4к. Видимо, для совместимости с загрузчиком.
Ели надо перенести куда-то массив - у вас проблемы. Просто вынуть диски тут, вставить там - можно получить что угодно вплоть до потери данных. Хоть и есть mdadm --scan
Заменить диск, судя по всему, тоже задача нетривиальная, по ссылке выше - требуется использовать fdisk и править разделы. Это не аппаратный массив с "вынул старый - вставил новый", и не gmirror c gmirror forget;gmirror insert ...
Совсем непонятно, как сделать рейд из одиночного диска без его форматирования, причем чтобы метаинформация сохранялась.
UPD: Перенос Centos Linux 5 с одного диска на Soft Raid
Моя ошибка была в том, что я начал с манов, а надо было начинать отсюда:
Вики (рус) - там тоже есть инфа по работе с массивом.
IPFW
Введение в работу с IPFW, на русском: http://ipfw.ism.kiev.ua/nipfw.html
Весьма полная дока: http://www.lissyara.su/doc/docs/handbook_-_ipfw/
Ещё про лимиты
Динамические правила выполняются не там, где они были созданы, а на первом вхождении check-state, или на первом правиле, имеющем предложение keep-state.
limit == keep-state limit
http://forum.nag.ru/forum/index.php?showtopic=16842
http://www.opennet.ru/openforum/vsluhforumID1/60814.html
http://www.opennet.ru/base/net/ipfw_dummynet_mask.txt.html
Внимание! Использование setup keep-state или limit чревато спаммом в messages ошибкой
ipfw: ipfw_install_state: Too many dynamic rules
За максимальное число правил отвечают sysctl
net.inet.ip.fw.dyn_buckets
net.inet.ip.fw.dyn_max
Смотреть через
net.inet.ip.fw.dyn_count
Но просто задрать это значение может не помочь - есть глюк/баг/фича, связанная с keep-alive. Подробнее
Еще почитать:
1, 2, 3, 4
Also, under DDoS, a good idea to enable full stealth mode for TCP and UDP.
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
Весьма полная дока: http://www.lissyara.su/doc/docs/handbook_-_ipfw/
Ещё про лимиты
Динамические правила выполняются не там, где они были созданы, а на первом вхождении check-state, или на первом правиле, имеющем предложение keep-state.
limit == keep-state limit
http://forum.nag.ru/forum/index.php?showtopic=16842
http://www.opennet.ru/openforum/vsluhforumID1/60814.html
http://www.opennet.ru/base/net/ipfw_dummynet_mask.txt.html
Внимание! Использование setup keep-state или limit чревато спаммом в messages ошибкой
ipfw: ipfw_install_state: Too many dynamic rules
За максимальное число правил отвечают sysctl
net.inet.ip.fw.dyn_buckets
net.inet.ip.fw.dyn_max
Смотреть через
net.inet.ip.fw.dyn_count
Но просто задрать это значение может не помочь - есть глюк/баг/фича, связанная с keep-alive. Подробнее
Еще почитать:
1, 2, 3, 4
Also, under DDoS, a good idea to enable full stealth mode for TCP and UDP.
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
четверг, 17 марта 2011 г.
Про MySQL: установка
Percona FreeBSD 2
yum, apt: link
MariaDB
Системное:
FreeBSD - cd /usr/ports/databases/mariadb && make install clean
Только проверить, что в системе нет оригинального mysql - используются те же пути и файлы.
# MariaDB OurDelta repository for Debian 5.0 «Lenny» binary packages.
deb mirror.ourdelta.org/deb lenny mariadb-ourdelta
deb-src mirror.ourdelta.org/deb lenny mariadb-ourdelta
link
Gentoo-style
echo dev-db/mysql xtradb >> /etc/portage/package.use/mysql
yum, apt: link
MariaDB
Системное:
FreeBSD - cd /usr/ports/databases/mariadb && make install clean
Только проверить, что в системе нет оригинального mysql - используются те же пути и файлы.
# MariaDB OurDelta repository for Debian 5.0 «Lenny» binary packages.
deb mirror.ourdelta.org/deb lenny mariadb-ourdelta
deb-src mirror.ourdelta.org/deb lenny mariadb-ourdelta
link
Gentoo-style
echo dev-db/mysql xtradb >> /etc/portage/package.use/mysql
Про MySQL: сборки
Ссылки - из "Про MySQL: введение"
1) Mysql
Пока официальный владелец, но их версия 5.1 считается самой медленной и имеет проблемы (на чем percona и выехала, за счет патчей гугля например). Хотя...
"Oracle тоже зашевелился и в версии 5.5 интегрированы патчи от Google, улучшена репликация, InnoDB 1.1 можно использовать новый формат хранения данных Barracuda. Установка google-perftools и сетап LD_PRELOAD также дают заметное увеличение производительности." link
2) MariaDB
сборка от Монти, синхронизирована с кодовой базой MySQL и полностью с ней совместим, т.е. может выступать в качестве прозрачной замены MySQL 5.1, обладая при этом рядом расширенных функций, включая оптимизации производительности и поставляясь с набором дополнительных движков хранилищ... (3)
3) Percona Server
сборка MySQL (от Петра Зайцева и ко) с включенным по умолчанию XtraDB storage engine. Отличается от MySQL+InnoDB plugin лучшей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Также улучшена функциональность — больше всякой полезной для оптимизации статистики и пр. Собирается в вариантах базирующихся на MySQL 5.0, 5.1 и 5.5. Полностью совместим с таблицами innodb, то есть можно переходить от innodb к xtradb и обратно без проблем (если не использовать некоторые специфичные для xtradb функции, типа меньшего размера страницы). (3)
4) Drizzle
Can I run a website with this?
No. We are still making incompatible changes, and certainly do not believe the code is production quality.
"MySQL 6 с небольшими модификациями. Не рекомендуется на production." link
Отличительная особенность в том, что в основе микроядро, а все возможности реализуются плагинами. Хоть плагины и удобны, при подключении всех плагинов производительность не может быть такой же, как на монолитной системе, но может быть на порядки быстрее на минимальном использовании плагинов или на собственных плагинах, заточенных под конкретную задачу.
Также есть шардинг - размещение базы на нескольких серверах, аналог raid striping.
5) OurDelta
"Активность в Ourdelta выдохлась — последний релиз был год назад. По-моему, вследствие появления deb-репозитариев у Percona. Я эту Ourdelta только из-за репозитария выбирал." link
6) ExtSQL — Extended Usage Statistics for SQL.
"Формально — форк, но со временем Percona подобрала все важные статистические возможности или сделала свои. Последняя активность тоже была год назад." Коммент тот же.
7) Есть key-based версия, тут рассматриваться не будет.
1) Mysql
Пока официальный владелец, но их версия 5.1 считается самой медленной и имеет проблемы (на чем percona и выехала, за счет патчей гугля например). Хотя...
"Oracle тоже зашевелился и в версии 5.5 интегрированы патчи от Google, улучшена репликация, InnoDB 1.1 можно использовать новый формат хранения данных Barracuda. Установка google-perftools и сетап LD_PRELOAD также дают заметное увеличение производительности." link
2) MariaDB
сборка от Монти, синхронизирована с кодовой базой MySQL и полностью с ней совместим, т.е. может выступать в качестве прозрачной замены MySQL 5.1, обладая при этом рядом расширенных функций, включая оптимизации производительности и поставляясь с набором дополнительных движков хранилищ... (3)
3) Percona Server
сборка MySQL (от Петра Зайцева и ко) с включенным по умолчанию XtraDB storage engine. Отличается от MySQL+InnoDB plugin лучшей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Также улучшена функциональность — больше всякой полезной для оптимизации статистики и пр. Собирается в вариантах базирующихся на MySQL 5.0, 5.1 и 5.5. Полностью совместим с таблицами innodb, то есть можно переходить от innodb к xtradb и обратно без проблем (если не использовать некоторые специфичные для xtradb функции, типа меньшего размера страницы). (3)
4) Drizzle
Can I run a website with this?
No. We are still making incompatible changes, and certainly do not believe the code is production quality.
"MySQL 6 с небольшими модификациями. Не рекомендуется на production." link
Отличительная особенность в том, что в основе микроядро, а все возможности реализуются плагинами. Хоть плагины и удобны, при подключении всех плагинов производительность не может быть такой же, как на монолитной системе, но может быть на порядки быстрее на минимальном использовании плагинов или на собственных плагинах, заточенных под конкретную задачу.
Также есть шардинг - размещение базы на нескольких серверах, аналог raid striping.
5) OurDelta
"Активность в Ourdelta выдохлась — последний релиз был год назад. По-моему, вследствие появления deb-репозитариев у Percona. Я эту Ourdelta только из-за репозитария выбирал." link
6) ExtSQL — Extended Usage Statistics for SQL.
"Формально — форк, но со временем Percona подобрала все важные статистические возможности или сделала свои. Последняя активность тоже была год назад." Коммент тот же.
7) Есть key-based версия, тут рассматриваться не будет.
Про MySQL: введение
После ознакомления с рядом документов (в конце) становится понятно: сам по себе mysql умрет еще не скоро, но и активно развиваться уже не будет - сейчас это конкурент ораклу в нижне-среднем сегменте.
На начало 2011 года.
Таблицы MyISAM прекрасно подходят для использования в WWW и других средах, где преобладают запросы на чтение. Таблицы типа MyISAM показывают хорошие результаты при выборках SELECT. Во многом это связано с отсутствием поддержки транзакций и внешних ключей. Однако при модификации и добавлении записей вся таблица кратковременно блокируется, это может привести к серьёзным задержкам при большой загрузке.
MyISAM
Из oracle ушло 70% программистов, многие их которых осели в компании SkySQL, которая делает свою версию - MariaDB.
Видео по теме: http://vimeo.com/20439614
Ссылки
1) http://www.blogerator.ru/page/mysql-na-steroidah
2) http://kb.askmonty.org/v/mariadb-versus-mysql
3) http://habrahabr.ru/blogs/mysql/108104/
4) http://ru.wikipedia.org/wiki/MySQL
На начало 2011 года.
Таблицы MyISAM прекрасно подходят для использования в WWW и других средах, где преобладают запросы на чтение. Таблицы типа MyISAM показывают хорошие результаты при выборках SELECT. Во многом это связано с отсутствием поддержки транзакций и внешних ключей. Однако при модификации и добавлении записей вся таблица кратковременно блокируется, это может привести к серьёзным задержкам при большой загрузке.
MyISAM
Из oracle ушло 70% программистов, многие их которых осели в компании SkySQL, которая делает свою версию - MariaDB.
Видео по теме: http://vimeo.com/20439614
Ссылки
1) http://www.blogerator.ru/page/mysql-na-steroidah
2) http://kb.askmonty.org/v/mariadb-versus-mysql
3) http://habrahabr.ru/blogs/mysql/108104/
4) http://ru.wikipedia.org/wiki/MySQL
управляемые розетки в стойки
Switched Rack PDU
http://www.apc.com/products/family/index.cfm?id=70
русская версия. Хотя моделей тут явно меньше. Понятно, что нет моделей на 120В.. Но похоже, нет и многих силовых.
Aten PN9108 8-Port Power Over the NET
http://www.aten.com/products/productItem.php?pid=20060417155437003
на русском
Rack-mount Transfer Switches
http://www.apc.com/products/family/index.cfm?id=14
Есть ещё такие штуки. Для подключения к 2 независимым энерговводам.
http://www.apc.com/products/family/index.cfm?id=70
русская версия. Хотя моделей тут явно меньше. Понятно, что нет моделей на 120В.. Но похоже, нет и многих силовых.
Aten PN9108 8-Port Power Over the NET
http://www.aten.com/products/productItem.php?pid=20060417155437003
на русском
Rack-mount Transfer Switches
http://www.apc.com/products/family/index.cfm?id=14
Есть ещё такие штуки. Для подключения к 2 независимым энерговводам.
вторник, 15 марта 2011 г.
robots.txt
Чтобы сказать роботам, куда нельзя лезть и сколько обращений можно делать - нужен файл robots.txt
Документ, как составлять, что писать. Достаточно подробное описание.
http://help.yandex.ru/webmaster/?id=996567
Автоматическое создание файла: http://htmlweb.ru/analiz/robots.php
Проверить правильность: http://webmaster.yandex.ru/robots.xml
Еще полезный сайт по теме: http://robotstxt.org.ru/
Очень много полезных ссылок и информации.
Документ, как составлять, что писать. Достаточно подробное описание.
http://help.yandex.ru/webmaster/?id=996567
Автоматическое создание файла: http://htmlweb.ru/analiz/robots.php
Проверить правильность: http://webmaster.yandex.ru/robots.xml
Еще полезный сайт по теме: http://robotstxt.org.ru/
Очень много полезных ссылок и информации.
пятница, 11 марта 2011 г.
SAS vs SSD
Небольшое вступление: SSD бывает 2 видов, MLC (Multi-Layer Cell) и SLC (Single Level Cell). И цена у них отличается в десятки раз за гигабайт. Так что брать?
Для веб-серверов под файлы пользователей имеет смысл брать MLC - у них ниже скорости чтения и записи, относительно маленький ресурс записей (порядка 10к на ячейку), но гуманная цена, хорошие емкости и за счет алгоритмов выравнивания износа ячеек приемлемое время жизни. А поскольку для данных файлов отношение чтение/запись обычно примерно 90/10, диски живут достаточно долго. При этом на случайном чтении 1 такой диск спокойно может заменить до 10 сас дисков за счет почти мгновенного выбора нужных блоков, поэтому оптимально как раз для мелких файлов вроде картинок, особенно thumbnails. Для больших файлов чтение уже скорее линейное, там линейной скорости таких дисков уже может быть мало.
Для БД уже лучше брать SLC - там нужно больше скорости, больше надежности. И тут SLC - лучший выбор.
SAS сейчас оптимален там, где большие емкости и нужно много IOPS - операций ввода-вывода. Прежде всего, это крупные БД. Но такие базы обычно занимают от 10 и до сотен дисков, всё-равно используя хорошо если 10% доступного места. А это много накладных расходов, много железа, много занятых юнитов "просто так"...
Самые оптимальные системы это смешанные, 3 уровней - SATA как медленное но очень ёмкое хранилице, SAS как более быстрое, но горячее, дорогое и менее ёмкое, и SSD как кэш для совсем большой скорости.
линк
Более простые решения - "Решение Adaptec MaxIQ SSD Cache Performance Solution включает в себя до четырех специально подготовленных SSD-накопителей Intel® X25-E Extreme SATA емкостью 32ГБ,..." линк
Для веб-серверов под файлы пользователей имеет смысл брать MLC - у них ниже скорости чтения и записи, относительно маленький ресурс записей (порядка 10к на ячейку), но гуманная цена, хорошие емкости и за счет алгоритмов выравнивания износа ячеек приемлемое время жизни. А поскольку для данных файлов отношение чтение/запись обычно примерно 90/10, диски живут достаточно долго. При этом на случайном чтении 1 такой диск спокойно может заменить до 10 сас дисков за счет почти мгновенного выбора нужных блоков, поэтому оптимально как раз для мелких файлов вроде картинок, особенно thumbnails. Для больших файлов чтение уже скорее линейное, там линейной скорости таких дисков уже может быть мало.
Для БД уже лучше брать SLC - там нужно больше скорости, больше надежности. И тут SLC - лучший выбор.
SAS сейчас оптимален там, где большие емкости и нужно много IOPS - операций ввода-вывода. Прежде всего, это крупные БД. Но такие базы обычно занимают от 10 и до сотен дисков, всё-равно используя хорошо если 10% доступного места. А это много накладных расходов, много железа, много занятых юнитов "просто так"...
Самые оптимальные системы это смешанные, 3 уровней - SATA как медленное но очень ёмкое хранилице, SAS как более быстрое, но горячее, дорогое и менее ёмкое, и SSD как кэш для совсем большой скорости.
линк
Более простые решения - "Решение Adaptec MaxIQ SSD Cache Performance Solution включает в себя до четырех специально подготовленных SSD-накопителей Intel® X25-E Extreme SATA емкостью 32ГБ,..." линк
четверг, 10 марта 2011 г.
Установка сертификата с подписью на месяц verisign-ом
Рассматривается система apache-backend+nginx-frontend
Есть варианты:
1) в обход nginx. Apache сразу слушает на 443 порту
2) nginx-proxy
3) сертификат на nginx, а дальше общение открытым текстом.
Впрочем, есть вариант "голого" nginx, без апача:
http://silverghost.org.ua/2010/10/27/nginx-ssl-shifrovanie/
Рассмотрим вариант 3
Для начала, надо проверить, что есть поддержка http_ssl_module, который надо подключать во фре.
cd /usr/ports/www/mginx
make config
Находим строчку HTTP_SSL_MODULE, ставим там крестик и пересобираем.
В centos штатно этот модуль есть и его надо просто подключить.
Создаем etc/nginx/cert и переходим туда
Есть неплохая дока от verisign по созданию сертификата под апач. Там же можно для пробы сделать 30-дневный ключ.
Создаем ключ.
openssl genrsa –des3 –out.key 2048
Ключ должен быть 2048 бит!
Retail customers Note: The recommended key bit size is 2048-bit. All certificates that will expire after October, 2013 must have a 2048 bit key size.
MPKI for SSL customers Note: The recommended key bit size is 2048-bit. All certificates that will expire after December, 2013 must have a 2048 bit key size.
Спросит пароль - его лучше ввести для защиты от утаскивания ключа. Если же безопасность не волнует, из строки генерации надо убрать -des3
Теперь создаем сертификат
openssl req –new –key.key –out .csr
Есть особенности заполнения, лучше читать доку с verisign - даже если и создаст сертификат, попытка его подписать в нормальном месте закончится неудачно, если что-то неверно.
В данном примере файл можно назвать как csr (Certificate Signing Request) и как .pem, главное придерживаться единого формата.
В common name вписываем адрес нашего сайта.
По заполнению CSR есть на русском - на ssl.ru. Обращаем внимание на заполнение поля о фирме:
"Форма собственности указывается исключительно латинскими буквами, либо в Европейской интерпретации. Например:
OOO = Ltd или LLC
OAO = OJSC, JSC или OAO (латинскими)
ZAO = CJSC или JSC."
Про почту:
"Please do not enter an email address, challenge password or an optional company name when generating the CSR.". С verisign
После перезапуска nginx обнаруживаем несколько неприятных моментов.
1) сертификат не принимает - неизвестный сертификат издателя
2) при перезапуске nginx просит пароль.
От 1 - надо на каждом клиенте импортировать сертификат.. Или подключить к своему сертификату корневой (verisign), но у меня не получилось - не хотел принимать.
syntax: ssl_certificate файл
default: нет
context: http, server
Директива указывает файл с сертификатом в формате PEM для данного виртуального сервера. Если вместе с основным сертификатом нужно указать промежуточные, то они должны находиться в этом же файле в следующем порядке — сначала основной сертификат, а затем промежуточные. В этом же файле может находиться секретный ключ в формате PEM.
отсюда
Сохранил корневой сертификат с ссылки выше и сделал cat verisign.pem >> my.pem, перезапустил нгинх... Не заработало. В смысле, всё-равно надо принимать исключение. Хотя мне уже кажется, проблема не в подключении, а в корневом сертификате...
Теперь вариант 1 - через apache
Тут есть свои нюансы, например сертификат проверяет имя, но обращается не по имени сайта, а по айпи. То есть, надо иметь по айпи на сертификат.
дока
Создаем хранилице сертификатов, например /etc/httpd/ssl
Копируем туда наши ключики. Переименовываем сертификат в .crt - требование апача.
Открываем раздел VirtualHost и пишем туда:
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
Этим мы включаем ssl.
Для апача можно указать отдельную директиву - корневой сертификат
SSLCACertificateFile – This will need to point to the the intermediate file
SSLCertificateFile – This will need to point to the your SSL certificate itself that we issued to you
SSLCertificateKeyFile – This will need to point to the private key file associated with your certificate.
Note: Some versions of Apache will not accept the SSLCACertificateFile directive. Try using SSLCertificateChainFile instead.
Перезапустим апач.. И получим УПС, если у нас не стоит mod_ssl. Во фре он собирается через make config && make deinstall && make reinstall
В центоси через yum install mod_ssl
Небольшая статья-подсказка
У меня уже были настроены хосты, поэтому я убрал штатно поставленный ssl.conf, скопировал основной хост, вписал в начало
Listen 443
LoadModule ssl_module modules/mod_ssl.so
NameVirtualHost *:443
(тут старые настройки) и в конец
SSLEngine on
SSLCertificateFile "/etc/httpd/ssl/s.crt"
SSLCertificateKeyFile "/etc/httpd/ssl/s.key"
SSLCertificateChainFile "/etc/httpd/ssl/verisign.crt"
Для пробы сойдет. Но надо бы за основу взять ssl.conf и подключать сайты оттуда.
==================
Если нам надоел запрос ключа при старте - снимем его так
$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
2. Make sure the server.key file is only readable by root:
$ chmod 400 server.key
===================
Частный/приватный ключ начинается со строки (.key)
-----BEGIN RSA PRIVATE KEY-----
Запрос на сертификат (.csr, .pem)
-----BEGIN CERTIFICATE REQUEST-----
Сертификат (.cert, .crt)
-----BEGIN CERTIFICATE-----
Инструкции у RapidSSL
Install certificate on apache
Generate a Certificate Signing Request (CSR) for Apache + Mod SSL + OpenSSL
Есть варианты:
1) в обход nginx. Apache сразу слушает на 443 порту
2) nginx-proxy
3) сертификат на nginx, а дальше общение открытым текстом.
Впрочем, есть вариант "голого" nginx, без апача:
http://silverghost.org.ua/2010/10/27/nginx-ssl-shifrovanie/
Рассмотрим вариант 3
Для начала, надо проверить, что есть поддержка http_ssl_module, который надо подключать во фре.
cd /usr/ports/www/mginx
make config
Находим строчку HTTP_SSL_MODULE, ставим там крестик и пересобираем.
В centos штатно этот модуль есть и его надо просто подключить.
Создаем etc/nginx/cert и переходим туда
Есть неплохая дока от verisign по созданию сертификата под апач. Там же можно для пробы сделать 30-дневный ключ.
Создаем ключ.
openssl genrsa –des3 –out
Ключ должен быть 2048 бит!
Retail customers Note: The recommended key bit size is 2048-bit. All certificates that will expire after October, 2013 must have a 2048 bit key size.
MPKI for SSL customers Note: The recommended key bit size is 2048-bit. All certificates that will expire after December, 2013 must have a 2048 bit key size.
Спросит пароль - его лучше ввести для защиты от утаскивания ключа. Если же безопасность не волнует, из строки генерации надо убрать -des3
Теперь создаем сертификат
openssl req –new –key
Есть особенности заполнения, лучше читать доку с verisign - даже если и создаст сертификат, попытка его подписать в нормальном месте закончится неудачно, если что-то неверно.
В данном примере файл можно назвать как csr (Certificate Signing Request) и как .pem, главное придерживаться единого формата.
В common name вписываем адрес нашего сайта.
По заполнению CSR есть на русском - на ssl.ru. Обращаем внимание на заполнение поля о фирме:
"Форма собственности указывается исключительно латинскими буквами, либо в Европейской интерпретации. Например:
OOO = Ltd или LLC
OAO = OJSC, JSC или OAO (латинскими)
ZAO = CJSC или JSC."
Про почту:
"Please do not enter an email address, challenge password or an optional company name when generating the CSR.". С verisign
После перезапуска nginx обнаруживаем несколько неприятных моментов.
1) сертификат не принимает - неизвестный сертификат издателя
2) при перезапуске nginx просит пароль.
От 1 - надо на каждом клиенте импортировать сертификат.. Или подключить к своему сертификату корневой (verisign), но у меня не получилось - не хотел принимать.
syntax: ssl_certificate файл
default: нет
context: http, server
Директива указывает файл с сертификатом в формате PEM для данного виртуального сервера. Если вместе с основным сертификатом нужно указать промежуточные, то они должны находиться в этом же файле в следующем порядке — сначала основной сертификат, а затем промежуточные. В этом же файле может находиться секретный ключ в формате PEM.
отсюда
Сохранил корневой сертификат с ссылки выше и сделал cat verisign.pem >> my.pem, перезапустил нгинх... Не заработало. В смысле, всё-равно надо принимать исключение. Хотя мне уже кажется, проблема не в подключении, а в корневом сертификате...
Теперь вариант 1 - через apache
Тут есть свои нюансы, например сертификат проверяет имя, но обращается не по имени сайта, а по айпи. То есть, надо иметь по айпи на сертификат.
дока
Создаем хранилице сертификатов, например /etc/httpd/ssl
Копируем туда наши ключики. Переименовываем сертификат в .crt - требование апача.
Открываем раздел VirtualHost и пишем туда:
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
Этим мы включаем ssl.
Для апача можно указать отдельную директиву - корневой сертификат
SSLCACertificateFile – This will need to point to the the intermediate file
SSLCertificateFile – This will need to point to the your SSL certificate itself that we issued to you
SSLCertificateKeyFile – This will need to point to the private key file associated with your certificate.
Note: Some versions of Apache will not accept the SSLCACertificateFile directive. Try using SSLCertificateChainFile instead.
Перезапустим апач.. И получим УПС, если у нас не стоит mod_ssl. Во фре он собирается через make config && make deinstall && make reinstall
В центоси через yum install mod_ssl
Небольшая статья-подсказка
У меня уже были настроены хосты, поэтому я убрал штатно поставленный ssl.conf, скопировал основной хост, вписал в начало
Listen 443
LoadModule ssl_module modules/mod_ssl.so
NameVirtualHost *:443
(тут старые настройки) и в конец
SSLEngine on
SSLCertificateFile "/etc/httpd/ssl/s.crt"
SSLCertificateKeyFile "/etc/httpd/ssl/s.key"
SSLCertificateChainFile "/etc/httpd/ssl/verisign.crt"
Для пробы сойдет. Но надо бы за основу взять ssl.conf и подключать сайты оттуда.
==================
Если нам надоел запрос ключа при старте - снимем его так
$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
2. Make sure the server.key file is only readable by root:
$ chmod 400 server.key
===================
Частный/приватный ключ начинается со строки (.key)
-----BEGIN RSA PRIVATE KEY-----
Запрос на сертификат (.csr, .pem)
-----BEGIN CERTIFICATE REQUEST-----
Сертификат (.cert, .crt)
-----BEGIN CERTIFICATE-----
Apache: выбираем сборку
Судя по Вики - основные версии prefork, worker, itk, peruser. Хотя порты freebsd показывают еще event, которого тут нету. Странно. Хотя гугль нашел
Если на сервере планируется больше 1 клиента - лучший выбор itk.
Для большинства задач подходит prefork, чаще всего и используется.
worker - "Среднезагруженные веб-серверы" (вики). Суть в том, что запускается много потоков, но каждый поток - несколько нитей. Должно обрабатывать больше клиентов при меньшем потреблении памяти, но в теории возможно получить информацию соседней нити.
event - This MPM is experimental, so it may or may not work as expected. За основу взят worker. Судя по описанию, использовать вместе с nginx бессмысленно.
А что берется для сильнозагруженного веб сервера с малым числом сайтов (1-10)? Попробуем worker, жизнь покажет правоту. Впрочем, сменить если что - не такая проблема.
Если на сервере планируется больше 1 клиента - лучший выбор itk.
Для большинства задач подходит prefork, чаще всего и используется.
worker - "Среднезагруженные веб-серверы" (вики). Суть в том, что запускается много потоков, но каждый поток - несколько нитей. Должно обрабатывать больше клиентов при меньшем потреблении памяти, но в теории возможно получить информацию соседней нити.
event - This MPM is experimental, so it may or may not work as expected. За основу взят worker. Судя по описанию, использовать вместе с nginx бессмысленно.
А что берется для сильнозагруженного веб сервера с малым числом сайтов (1-10)? Попробуем worker, жизнь покажет правоту. Впрочем, сменить если что - не такая проблема.
среда, 9 марта 2011 г.
суббота, 5 марта 2011 г.
redmine, nginx и 502 Bad Gateway
Обнаружил интересную штуку: если есть в конфигах nginx хоть 1 домен с ssl, при nginx reload при попытке зайти на сайт с redmine получим 502 Bad Gateway
При этом в логах
2011/03/05 16:30:28 [crit] 35380#0: *31325 connect() to unix:/passenger_helper_server failed (2: No such file or directory) while connecting to upstream, client: 192.168.0.1, server: redmine.file.wm, request: "GET / HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "redmine.site.ru"
Но после nginx restart - всё запускается, так что это видимо баг в nginx.
nginx -v
nginx version: nginx/0.8.54
Сделано через passenger.
При этом в логах
2011/03/05 16:30:28 [crit] 35380#0: *31325 connect() to unix:/passenger_helper_server failed (2: No such file or directory) while connecting to upstream, client: 192.168.0.1, server: redmine.file.wm, request: "GET / HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "redmine.site.ru"
Но после nginx restart - всё запускается, так что это видимо баг в nginx.
nginx -v
nginx version: nginx/0.8.54
Сделано через passenger.
vsftpd - 530 Permission denied.
При попытке зайти по фтп, выдавало
530 Permission denied.
Под разными пользователями (не рутом), на всех такое.
Есть решение для 3.0.0+: allow_writeable_chroot=YES
For the extended vsFTPd build (vsftpd-ext):
allow_writable_chroot=YES
Обновление vsftpd под дебианом/убунтой
Here are the steps to be taken (copy paste from the tutorial, in case the link dies)
login as root (or sudo..) and do the following:
apt-get install python-software-properties
sudo add-apt-repository ppa:thefrontiergroup/vsftpd
sudo apt-get update
sudo apt-get install vsftpd
echo "allow_writeable_chroot=YES" >> allow_writeable_chroot=YES
sudo service vsftpd restart
Если что - доки о настройке
официальный
перевод большинства опций
http://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/
http://www.boxtricks.com/500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/
http://stackoverflow.com/questions/16102996/vsftpd-refusing-to-run-with-writable-root-inside-chroot
530 Permission denied.
Под разными пользователями (не рутом), на всех такое.
Есть решение для 3.0.0+: allow_writeable_chroot=YES
For the extended vsFTPd build (vsftpd-ext):
allow_writable_chroot=YES
Обновление vsftpd под дебианом/убунтой
Here are the steps to be taken (copy paste from the tutorial, in case the link dies)
login as root (or sudo..) and do the following:
apt-get install python-software-properties
sudo add-apt-repository ppa:thefrontiergroup/vsftpd
sudo apt-get update
sudo apt-get install vsftpd
echo "allow_writeable_chroot=YES" >> allow_writeable_chroot=YES
sudo service vsftpd restart
Если что - доки о настройке
официальный
перевод большинства опций
http://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/
http://www.boxtricks.com/500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/
http://stackoverflow.com/questions/16102996/vsftpd-refusing-to-run-with-writable-root-inside-chroot
среда, 2 марта 2011 г.
Еще один аналог putty
ISPManager смена типа лицензии
1) с лайта на про
меняем лицензию
запускаем /usr/local/ispmgr/sbin/up2prof.sh
2) С про на лайт
опять же, меняем лицензию
качаем http://blog.ihtiandr.info/wp-content/uploads/ispmanager/down2lite.sh
меняем лицензию
запускаем /usr/local/ispmgr/sbin/up2prof.sh
2) С про на лайт
опять же, меняем лицензию
качаем http://blog.ihtiandr.info/wp-content/uploads/ispmanager/down2lite.sh
Подписаться на:
Сообщения (Atom)