Указал бы оригинал, но он просто засран всяким сеошным мусором.
понедельник, 10 сентября 2012 г.
пятница, 31 августа 2012 г.
freebsd: модульный ipfw - особенность настройки
По умолчанию ipfw в виде модуля работает в режиме запрета, поэтому после включения в rc.conf строкой firewall_enabled=YES можно получить недоступную систему. По живому изменить поведение нельзя:
# sysctl -w net.inet.ip.fw.default_to_accept=1
sysctl: oid 'net.inet.ip.fw.default_to_accept' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf
Особенность в том, что обычно параметры для sysctl правятся в /etc/sysctl.conf, но не в данном случае! Тут надо вписывать именно в /boot/loader.conf:
net.inet.ip.fw.default_to_accept=1
Вариант 2, не такой красивый и более опасный: в rc.conf
firewall_enable="YES"
#firewall_type="/etc/firewall.conf"
firewall_type="open"
(строка с type="/etc/firewall.conf" закомментирована)
Проблем будет больше, в частности с ipfw -f flush - всё отвалится.
# sysctl -w net.inet.ip.fw.default_to_accept=1
sysctl: oid 'net.inet.ip.fw.default_to_accept' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf
Особенность в том, что обычно параметры для sysctl правятся в /etc/sysctl.conf, но не в данном случае! Тут надо вписывать именно в /boot/loader.conf:
net.inet.ip.fw.default_to_accept=1
Вариант 2, не такой красивый и более опасный: в rc.conf
firewall_enable="YES"
#firewall_type="/etc/firewall.conf"
firewall_type="open"
(строка с type="/etc/firewall.conf" закомментирована)
Проблем будет больше, в частности с ipfw -f flush - всё отвалится.
четверг, 30 августа 2012 г.
Fetching 4 new ports or files... gunzip: unknown compression format
Иногда при portsnap fetch update вылезает ошибка
Fetching 4 new ports or files... gunzip: unknown compression format
которую очень сложно поправить. Иногда оно правится удалением базы и повторным выкачиванием (rm -r /var/db/portsnap/*), иногда это не помогает. Причина обычно - какой-то сбой на серверах обновлений, надо выяснить, откуда пытаемся обновиться и забаннить его, например через внесение этого имени в hosts или просто указанием, с какого конкретно сервера хотим обновиться.
Fetching 4 new ports or files... gunzip: unknown compression format
которую очень сложно поправить. Иногда оно правится удалением базы и повторным выкачиванием (rm -r /var/db/portsnap/*), иногда это не помогает. Причина обычно - какой-то сбой на серверах обновлений, надо выяснить, откуда пытаемся обновиться и забаннить его, например через внесение этого имени в hosts или просто указанием, с какого конкретно сервера хотим обновиться.
среда, 22 августа 2012 г.
selectel: увеличиваем диск
Для паркинга уже была инструкция, теперь для selectel, уже вкратце.
Имеем: отдельный диск под /var/www, расположенный на диске /dev/xvdb, целиком отданным под lvm, с именем vg--www-www (группа vg-www, имя www), путь /dev/vg-www/www
Вариант с выключением для изменения размера -- вменяемых описаний, как это делать без перезагрузки, пока не найдено. Есть дока, но по ней не получилось.
Размер в панели уже увеличен.
Для начала, надо будет отмонтировать раздел. (umount)
Смотрим где наш том
pvdisplay
Растянем на весь новый диск.
pvresize /dev/xvdb
pvdisplay
Alloc PE / Size 8191 / 32.00 GiB
Free PE / Size 8192 / 32.00 GiB
Было 32, стало 64. Нормально.
Теперь надо увеличить наш том
# lvextend -l +100%FREE /dev/vg-www/www
Extending logical volume www to 64.00 GiB
Logical volume www successfully resized
И файловую систему.
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg-www/www' first.
# e2fsck -f /dev/vg-www/www
...
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/vg-www/www to 16776192 (4k) blocks.
С первого запуска не прошло - надо сначала проверить раздел.
Всё, можно монтировать и работать.
Можно попробовать ptmax, но не совсем понятно, в какое место ей тыкать.
Надо выжать из саппорта селектела их вариант без перезагрузки, пока у меня не получилось.
Имеем: отдельный диск под /var/www, расположенный на диске /dev/xvdb, целиком отданным под lvm, с именем vg--www-www (группа vg-www, имя www), путь /dev/vg-www/www
Вариант с выключением для изменения размера -- вменяемых описаний, как это делать без перезагрузки, пока не найдено. Есть дока, но по ней не получилось.
Размер в панели уже увеличен.
Для начала, надо будет отмонтировать раздел. (umount)
Смотрим где наш том
pvdisplay
Растянем на весь новый диск.
pvresize /dev/xvdb
pvdisplay
Alloc PE / Size 8191 / 32.00 GiB
Free PE / Size 8192 / 32.00 GiB
Было 32, стало 64. Нормально.
Теперь надо увеличить наш том
# lvextend -l +100%FREE /dev/vg-www/www
Extending logical volume www to 64.00 GiB
Logical volume www successfully resized
И файловую систему.
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg-www/www' first.
# e2fsck -f /dev/vg-www/www
...
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/vg-www/www to 16776192 (4k) blocks.
С первого запуска не прошло - надо сначала проверить раздел.
Всё, можно монтировать и работать.
Можно попробовать ptmax, но не совсем понятно, в какое место ей тыкать.
Надо выжать из саппорта селектела их вариант без перезагрузки, пока у меня не получилось.
вторник, 21 августа 2012 г.
400 Bad Request Request Header Or Cookie Too Large
Самое просто решение - почистить куки. Если же сервер наш, можно подкрутить настройки серверов:
для nginx это
large_client_header_buffers 4 8k;
Можно выставить например 16к, но дальше будет ошибка
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.
Потому что надо увеличить эти же значения и для apache
LimitRequestFieldSize 8190
Можно выставить
LimitRequestFieldSize 16380
Но проблема может быть и по другой причине.
Включаем в nginx.conf строку
error_log /var/log/nginx/error.log info;
И видим в логе
2012/11/28 13:15:42 [info] 77783#0: *1146484 client sent too long header line: "X-Forwarded-For: 1.2.123.24, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, ..." while reading client request headers, client: 127.0.0.1, server: _, request: "GET / HTTP/1.0", host: "site.ru"
для nginx это
large_client_header_buffers 4 8k;
Можно выставить например 16к, но дальше будет ошибка
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.
Потому что надо увеличить эти же значения и для apache
LimitRequestFieldSize 8190
Можно выставить
LimitRequestFieldSize 16380
Но проблема может быть и по другой причине.
Включаем в nginx.conf строку
error_log /var/log/nginx/error.log info;
И видим в логе
2012/11/28 13:15:42 [info] 77783#0: *1146484 client sent too long header line: "X-Forwarded-For: 1.2.123.24, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, ..." while reading client request headers, client: 127.0.0.1, server: _, request: "GET / HTTP/1.0", host: "site.ru"
Это признаки циклического редиректа, например в proxy_pass указан тот же порт, на котором сидит сам nginx (и так бывает иногда, да)
суббота, 18 августа 2012 г.
Очередная авария в selectel
В 19.10 сегодня (17.08) произошел сбой:
"К сожалению, случилась авария со связностью в сети облака, мы работаем над её устранением. Пострадавшие машины будут перезагружены.
Потерь данных не прогнозируется. "
Видимо, хваленое дублированное СХД не помогло.
До сих пор (18.08, 00:20):
"Пострадавшие виртуальные машины запускаются. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. "
и
"Пострадавшие виртуальные машины запускаются. В результате ошибочной коммутации часть хранилищ оказалась отключенной от хостов виртуализации. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. Компенсация за даунтайм будет предоставлена в начале следующего месяца. Приносим извинения за созданные проблемы. "
"К сожалению, случилась авария со связностью в сети облака, мы работаем над её устранением. Пострадавшие машины будут перезагружены.
Потерь данных не прогнозируется. "
Видимо, хваленое дублированное СХД не помогло.
До сих пор (18.08, 00:20):
"Пострадавшие виртуальные машины запускаются. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. "
и
"Пострадавшие виртуальные машины запускаются. В результате ошибочной коммутации часть хранилищ оказалась отключенной от хостов виртуализации. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. Компенсация за даунтайм будет предоставлена в начале следующего месяца. Приносим извинения за созданные проблемы. "
понедельник, 6 августа 2012 г.
freebsd и percona mysql
На сегодняшний день перкона-сборка сломана. Есть набор патчей:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/164072
Но
1) патчи аж февральские, но до сих пор не втянуты
2) даже после ручного применения могут быть проблемы.
Так что пока или воевать с конфликтами сборки, или ставить пакетами, или использовать пока оф версию или марию (mariadb)
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/164072
Но
1) патчи аж февральские, но до сих пор не втянуты
2) даже после ручного применения могут быть проблемы.
Так что пока или воевать с конфликтами сборки, или ставить пакетами, или использовать пока оф версию или марию (mariadb)
среда, 1 августа 2012 г.
exim, гугл и ipv6
# echo "test www1" | mail -v -s "testing www1" (skip)@gmail.com LOG: MAIN <= root@server.spb.ru U=root P=local S=396 # delivering 1SwU4n-000NDx-Fz Connecting to gmail-smtp-in.l.google.com [2a00:1450:8005::1a]:25 ... LOG: MAIN PANIC DIE unable to parse "2a00:1450:8005::1a" as an IP address: ai_family not supported LOG: MAIN == (skip)@gmail.com R=dnslookup T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x0100: exit code 1 LOG: MAIN Frozen
Причина в том, что по какой-то причине система пытается отправить по ipv6, и при невозможности - просто забивает, вместо пробы другого протокола. Может возникнуть в частности при собранном exim с ipv6 и отключенным ипв6 в самой системе.
Решение: ставить exim без поддержки ипв6 или добавить в конфиг опцию
disable_ipv6 = yes
и перезапустить сервис. Мне было проще пересобрать без ipv6 вообще, поскольку всё-равно пока протокол сырой и ещё лет 5 для внедрения допустим только после тщательных тестов. И минимум несколько лет после массового перехода в протоколе будут находить критические дыры.
вторник, 17 июля 2012 г.
Облака, за и против (2)
Несколько разверну заметку (1)
Казалось бы, полное дублирование оборудования, дорогие СХД, дорогие и быстрые технологии... И при этом оплата только по потреблению. Казалось бы, рай. Про настоящие и "маркетинговые" облака напишу в другой раз.
С момента зарождения облаков прошло уже несколько лет, появились отзывы.. И стало понятно, что у облаков тоже есть проблемы, просто эти проблемы другие. Что может быть с реальным сервером? Пропало питание, сгорел процессор, пробило память, выгорел порт в свиче, посыпался жесткий диск... 90% проблем касаются чисто технической стороны, подлежат предсказанию и принятию мер заранее. А также требуют обслуживания именно как оборудование.
В облаках проблемы другие. В основном это проблемы с СХД, потери связности, а также очень много - "человеческий фактор". Хороший пример -- clodo (линки ниже).
Плюс у облаков есть ряд проблем, которые все любят "опровергать", и которые на практике только многократно подтверждаются. (та же безопасность и linode), и одна из реальных главных проблем честного облака - крайне сложно предсказать расходы. День ддоса - и весь бюджет на 3 месяца вперёд съеден.
По всем ссылкам также читать комменты.
Selectel
2 облачные системы, спб-1 и спб-2. В спб-1 периодически выпадала СХД, ввели СПб-2 со своими косяками и багами. Главное отличие спб-2 в том, что там уже не 1 СХД, а несколько.
Проблемы есть, но в виде резерва нас оно устраивает полностью + поддержка масштабирования памяти (увы, от мин до макс не более х8, например 256мб-1гб). Самым дорогим ресурсом для нас выходит всё-таки диск, и это единственное, что масштабируется напильником и остановкой сервера, и оплата за выделение места + потребление иопс. В остальном настоящее облако.
Зимой (2011-2012) была проблема с тем, что их облако просто исчерпало лимиты масштабируемости, поэтому создание машин было приостановлено, и потом запущена система спб-2.
Прощай, Selectel
в комментах
Опять авария в облаке Selectel… Доколе?
Clodo
Вроде мегасистема с хранилищем на infiniband, на практике весьма проблемный.
Есть несколько ДЦ, в том числе в оверсан-меркурий, который даёт своё облако Scalaxy
Приключения с Clodo: про земной и заоблачный подход к работе
Clodo.ru и очередное загадочное падение
CLODO — опять лежим или нужно предупреждать заранее
Scalaxy
Особо не изучали: по отзывам, не очень стабильны и весьма дорогие.
О проблемах:
Облако cannot be read
Amazon
"Эталон" облаков, хотя он менее облачный чем даже селектел и представляет из себя просто виртуальную машину (VDS) с автомиграцией на новую ноду в случае чего. Диски тоже, оплата не за реально занятое место (EBS которые), а за выделенное место. Плюс все операции платные, хоть и крайне дешёвые. Но даже в таком виде есть знатные падения.
Рассказ о том, как молния «убила» облако Amazon. По отзывам, простой "супер надёжной системы с 99.9999% (вроде)" надёжностью составил порядка 5 суток.
Есть проблемы и помельче.
"Прямо как я недавно свалил со Scalaxy. Как раз-таки на Selectel. Имхо, так вечно бегать можно. У моего друга подобная неприятность случалась на AWS. Подумать только, сам Amazon, с их то ценами… Амазон, конечно, сам выслал нотификацию о проблеме, и предлагал компенсацию — но потерянная машина была просто тестовой средой, представляющей из себя просто свежеустановленный Debian с FTP+Nginx."
http://habrahabr.ru/post/145647/
"как человек, который амазон пользовал, скажу — там далеко не радужно.
и если виртуалка падает — амазон предлагает запустить новую.
диски надо? используйте persistent. ах, вы не подключали его? извините.
ах подключали, и не доступно? поднимайте snapshot.
ах, вы его не делали? извините, сами дураки.
ах, они не доступны? извините, или подождите и может станет доступным, или сами дураки что снапшоты не лили в другую зону."
http://habrahabr.ru/post/145112/
Rackspace
Считается конкурентом амазону, тоже весьма дорогим. Ссылками возможно дополню позднее.
Jira
У нас не сильно известен, но тут за славный факап "We've completely lost all your data":
"Проблемы случаются не только в России, перевел среду разработки на облачный хостинг: Task Management, Issue Tracker, Subversion, Builds, Wiki. На прошлой неделе в четверг у них все свалилось, к выходным обещали починить. В понедельник прислали письмо: We've completely lost all your data. хостинг к слову в Англии Jira.com"
http://habrahabr.ru/post/143056/#comment_4793925
Итог
Облака могут быть хороши, особенно на старте. Но они же могут съесть все бюджеты при любой ошибке или ддосе. И если с реальной железкой можно защититься, задублировав почти всё, то с облаками надо тоже дублироваться, но уже в другое облако, в другую страну, и лучше вообще другой компании. А также всегда делать бэкапы. Облако - не панацея, и не спасёт от умышленного удаления данных с автоматическим дублированием этого по всем зеркалам.
"3) облачная виртуализация — всего-лишь способ добиться высокой плотности размещения виртуалок на физике. Удобно для хостера, но никак не панацея для клиента."
http://habrahabr.ru/post/120303/#comment_3943417
По мере изучения отзывов стали попадаться вещи вроде "лежим 10 часов... уже 18 часов.. Потеряны деньги и репутация!". А можно вспомнить сбои в любимом всеми амазоне, где были падения на 5 дней. И небольшой вопрос тем, кто потом плачется про огромные потери: А что сделали лично ВЫ, чтобы не допустить этих самых простоев? "Ну вот сейчас всё поднимется, мы заберём проект, бэкапы и уйдём к другим". И тут уместно вспомнить клиентов макхоста, которым отдавали их сайты по 3 месяца.. hosting.ua, у которого ряд серверов просто сгорел, с данными.. Особенно смешно смотрятся фразы "подорвана репутация одного проекта, которую не за какие деньги теперь не восстановить, я делал компенсации и бонусы сколько мог своим пользователям за каждое ваше падение. Что мне теперь делать не представляю.". Видимо, теперь человек представляет как минимум 1 необходимое действие: бэкапы. И минимум в 2 места, а лучше в 3-4. Предполагаю, что после этого такие люди всё-таки начнут делать бэкапы. А у нас уже несколько лет для таких критичных сайтов есть ещё полная копия в горячем резерве, с репликацией баз master-slave с быстрым переключением днс на новое место. А для минимизации расходов - первое место свои железки, а второе как раз облака. И когда в очередной раз облака отваливаются - ничего страшного, это только зеркало. Ну и бэкапы в несколько мест, включая амазон.
Казалось бы, полное дублирование оборудования, дорогие СХД, дорогие и быстрые технологии... И при этом оплата только по потреблению. Казалось бы, рай. Про настоящие и "маркетинговые" облака напишу в другой раз.
С момента зарождения облаков прошло уже несколько лет, появились отзывы.. И стало понятно, что у облаков тоже есть проблемы, просто эти проблемы другие. Что может быть с реальным сервером? Пропало питание, сгорел процессор, пробило память, выгорел порт в свиче, посыпался жесткий диск... 90% проблем касаются чисто технической стороны, подлежат предсказанию и принятию мер заранее. А также требуют обслуживания именно как оборудование.
В облаках проблемы другие. В основном это проблемы с СХД, потери связности, а также очень много - "человеческий фактор". Хороший пример -- clodo (линки ниже).
Плюс у облаков есть ряд проблем, которые все любят "опровергать", и которые на практике только многократно подтверждаются. (та же безопасность и linode), и одна из реальных главных проблем честного облака - крайне сложно предсказать расходы. День ддоса - и весь бюджет на 3 месяца вперёд съеден.
По всем ссылкам также читать комменты.
Selectel
2 облачные системы, спб-1 и спб-2. В спб-1 периодически выпадала СХД, ввели СПб-2 со своими косяками и багами. Главное отличие спб-2 в том, что там уже не 1 СХД, а несколько.
Проблемы есть, но в виде резерва нас оно устраивает полностью + поддержка масштабирования памяти (увы, от мин до макс не более х8, например 256мб-1гб). Самым дорогим ресурсом для нас выходит всё-таки диск, и это единственное, что масштабируется напильником и остановкой сервера, и оплата за выделение места + потребление иопс. В остальном настоящее облако.
Зимой (2011-2012) была проблема с тем, что их облако просто исчерпало лимиты масштабируемости, поэтому создание машин было приостановлено, и потом запущена система спб-2.
Прощай, Selectel
в комментах
Опять авария в облаке Selectel… Доколе?
Clodo
Вроде мегасистема с хранилищем на infiniband, на практике весьма проблемный.
Есть несколько ДЦ, в том числе в оверсан-меркурий, который даёт своё облако Scalaxy
Приключения с Clodo: про земной и заоблачный подход к работе
Clodo.ru и очередное загадочное падение
CLODO — опять лежим или нужно предупреждать заранее
Scalaxy
Особо не изучали: по отзывам, не очень стабильны и весьма дорогие.
О проблемах:
Облако cannot be read
Amazon
"Эталон" облаков, хотя он менее облачный чем даже селектел и представляет из себя просто виртуальную машину (VDS) с автомиграцией на новую ноду в случае чего. Диски тоже, оплата не за реально занятое место (EBS которые), а за выделенное место. Плюс все операции платные, хоть и крайне дешёвые. Но даже в таком виде есть знатные падения.
Рассказ о том, как молния «убила» облако Amazon. По отзывам, простой "супер надёжной системы с 99.9999% (вроде)" надёжностью составил порядка 5 суток.
Есть проблемы и помельче.
"Прямо как я недавно свалил со Scalaxy. Как раз-таки на Selectel. Имхо, так вечно бегать можно. У моего друга подобная неприятность случалась на AWS. Подумать только, сам Amazon, с их то ценами… Амазон, конечно, сам выслал нотификацию о проблеме, и предлагал компенсацию — но потерянная машина была просто тестовой средой, представляющей из себя просто свежеустановленный Debian с FTP+Nginx."
http://habrahabr.ru/post/145647/
"как человек, который амазон пользовал, скажу — там далеко не радужно.
и если виртуалка падает — амазон предлагает запустить новую.
диски надо? используйте persistent. ах, вы не подключали его? извините.
ах подключали, и не доступно? поднимайте snapshot.
ах, вы его не делали? извините, сами дураки.
ах, они не доступны? извините, или подождите и может станет доступным, или сами дураки что снапшоты не лили в другую зону."
http://habrahabr.ru/post/145112/
Rackspace
Считается конкурентом амазону, тоже весьма дорогим. Ссылками возможно дополню позднее.
Jira
У нас не сильно известен, но тут за славный факап "We've completely lost all your data":
"Проблемы случаются не только в России, перевел среду разработки на облачный хостинг: Task Management, Issue Tracker, Subversion, Builds, Wiki. На прошлой неделе в четверг у них все свалилось, к выходным обещали починить. В понедельник прислали письмо: We've completely lost all your data. хостинг к слову в Англии Jira.com"
http://habrahabr.ru/post/143056/#comment_4793925
Итог
Облака могут быть хороши, особенно на старте. Но они же могут съесть все бюджеты при любой ошибке или ддосе. И если с реальной железкой можно защититься, задублировав почти всё, то с облаками надо тоже дублироваться, но уже в другое облако, в другую страну, и лучше вообще другой компании. А также всегда делать бэкапы. Облако - не панацея, и не спасёт от умышленного удаления данных с автоматическим дублированием этого по всем зеркалам.
"3) облачная виртуализация — всего-лишь способ добиться высокой плотности размещения виртуалок на физике. Удобно для хостера, но никак не панацея для клиента."
http://habrahabr.ru/post/120303/#comment_3943417
По мере изучения отзывов стали попадаться вещи вроде "лежим 10 часов... уже 18 часов.. Потеряны деньги и репутация!". А можно вспомнить сбои в любимом всеми амазоне, где были падения на 5 дней. И небольшой вопрос тем, кто потом плачется про огромные потери: А что сделали лично ВЫ, чтобы не допустить этих самых простоев? "Ну вот сейчас всё поднимется, мы заберём проект, бэкапы и уйдём к другим". И тут уместно вспомнить клиентов макхоста, которым отдавали их сайты по 3 месяца.. hosting.ua, у которого ряд серверов просто сгорел, с данными.. Особенно смешно смотрятся фразы "подорвана репутация одного проекта, которую не за какие деньги теперь не восстановить, я делал компенсации и бонусы сколько мог своим пользователям за каждое ваше падение. Что мне теперь делать не представляю.". Видимо, теперь человек представляет как минимум 1 необходимое действие: бэкапы. И минимум в 2 места, а лучше в 3-4. Предполагаю, что после этого такие люди всё-таки начнут делать бэкапы. А у нас уже несколько лет для таких критичных сайтов есть ещё полная копия в горячем резерве, с репликацией баз master-slave с быстрым переключением днс на новое место. А для минимизации расходов - первое место свои железки, а второе как раз облака. И когда в очередной раз облака отваливаются - ничего страшного, это только зеркало. Ну и бэкапы в несколько мест, включая амазон.
понедельник, 16 июля 2012 г.
<sys-apps/sysvinit-2.88-r3 ("<sys-apps/sysvinit-2.88-r3" is blocking sys-apps/util-linux-2.20.1-r1)
При попытке обновления однажды вылезает
# emerge -p --update --deep --newuse world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/glibc-2.14.1-r3 [2.13-r4]
[ebuild R ] sys-devel/gettext-0.18.1.1-r1 USE="-git*"
[ebuild R ] sys-devel/binutils-2.21.1-r1 USE="cxx%*"
[ebuild U ] sys-devel/gcc-4.5.3-r2 [4.5.3-r1]
[ebuild R ] sys-apps/busybox-1.19.3-r1 USE="-livecd%"
[ebuild R ] sys-apps/portage-2.1.10.49 USE="(-pypy1_9) (-pypy1_8%)"
[ebuild U ] sys-apps/util-linux-2.20.1-r1 [2.19.1-r1] USE="-ddate% -static-libs%"
[ebuild U ] sys-apps/sysvinit-2.88-r3 [2.88-r2]
[blocks b ]
При попытке обновить что-либо из заблокированного ничего не получится... Делать надо так:
# emerge --update sysvinit util-linux
# emerge -p --update --deep --newuse world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/glibc-2.14.1-r3 [2.13-r4]
[ebuild R ] sys-devel/gettext-0.18.1.1-r1 USE="-git*"
[ebuild R ] sys-devel/binutils-2.21.1-r1 USE="cxx%*"
[ebuild U ] sys-devel/gcc-4.5.3-r2 [4.5.3-r1]
[ebuild R ] sys-apps/busybox-1.19.3-r1 USE="-livecd%"
[ebuild R ] sys-apps/portage-2.1.10.49 USE="(-pypy1_9) (-pypy1_8%)"
[ebuild U ] sys-apps/util-linux-2.20.1-r1 [2.19.1-r1] USE="-ddate% -static-libs%"
[ebuild U ] sys-apps/sysvinit-2.88-r3 [2.88-r2]
[blocks b ]
При попытке обновить что-либо из заблокированного ничего не получится... Делать надо так:
# emerge --update sysvinit util-linux
пятница, 13 июля 2012 г.
Как стать микрохостером
Для начала, надо определиться с видом деятельности - сдавать оборудование, vds, просто хостить сайты..
Сразу оговоримся, что услуг связи и криптования (vpn) не предоставляем, это отдельный набор документов и долгое общение с ФСБ.
Чтобы просто перепродавать чужие услуги, надо стать хотя бы ИП и стать агентом, указывая, чьи услуги продаются.
Также чтобы просто сдавать чужое оборудование, в виде целых железок, тоже лицензий не надо.
А вот если сдавать услугу (хостинг сайтов, вдс-ов итд) - это уже подпадает под категорию "хостер".
В идеале, хостер - юр лицо, с сертификатами на телематику, своим сданным узлом связи, с разрешением на эксплуатацию в Роскомнадзоре (1)
Для начала, что надо.
Нужна ли лицензия хостеру? (2)
Сдача узла связи для хостинговых компаний
На своё оборудование ССС обязателен. Сертификаты соответствия - оборудование должно быть сертифицировано для оказания услуг связи.
Получать ли лицензию на телематику - вопрос очень спорный, и по ссылкам (например (2)) ясности не добавится. Так что телематику лучше получить:
Без лицензии -- статья 171 уголовного кодекса; с лицензией без сданного узла связи - штраф до 20 тыс. руб. в соответствии с КоАП.
http://forum.hostobzor.ru/lofiversion/index.php/t8585.html
Вот узел связи во многих случаях получается можно и не сдавать, пока обороты не превысят 5-10 млн в год - закрыть-то можно легко, а вот денег состричь уже не сильно выйдет. А если будет именно указание закрыть - и наличие всех документов не поможет. Хотя при хороших оборотах лучше всё-таки озаботиться всеми лицензиями.
Сразу оговоримся, что услуг связи и криптования (vpn) не предоставляем, это отдельный набор документов и долгое общение с ФСБ.
Чтобы просто перепродавать чужие услуги, надо стать хотя бы ИП и стать агентом, указывая, чьи услуги продаются.
Также чтобы просто сдавать чужое оборудование, в виде целых железок, тоже лицензий не надо.
А вот если сдавать услугу (хостинг сайтов, вдс-ов итд) - это уже подпадает под категорию "хостер".
В идеале, хостер - юр лицо, с сертификатами на телематику, своим сданным узлом связи, с разрешением на эксплуатацию в Роскомнадзоре (1)
Для начала, что надо.
Нужна ли лицензия хостеру? (2)
Сдача узла связи для хостинговых компаний
На своё оборудование ССС обязателен. Сертификаты соответствия - оборудование должно быть сертифицировано для оказания услуг связи.
Получать ли лицензию на телематику - вопрос очень спорный, и по ссылкам (например (2)) ясности не добавится. Так что телематику лучше получить:
Без лицензии -- статья 171 уголовного кодекса; с лицензией без сданного узла связи - штраф до 20 тыс. руб. в соответствии с КоАП.
http://forum.hostobzor.ru/lofiversion/index.php/t8585.html
Вот узел связи во многих случаях получается можно и не сдавать, пока обороты не превысят 5-10 млн в год - закрыть-то можно легко, а вот денег состричь уже не сильно выйдет. А если будет именно указание закрыть - и наличие всех документов не поможет. Хотя при хороших оборотах лучше всё-таки озаботиться всеми лицензиями.
четверг, 12 июля 2012 г.
Новые процессоры intel: square и narrow сокеты
"Следующим новшеством платформ, стало применение двух типов установочных сокетов под процессоры ILM (Independent Loading Mechanism). Называются они Square ILM и Narrow ILM. Отличаются они размерами крепежных отверстий: в Square ILM 80×80, а Narrow ILM 94×56. Под каждый тип крепления, будут необходимы свои типы радиаторы или соответственно кулера, линейка которых значительно расширилась. Теперь при выборе устройств охлаждения, под 26xx серию процессоров, надо быть внимательней, т.к. ОНИ НЕ ВЗАИМОЗАМЕНЯЕМЫ, т.е. радиатор или кулер под Square ILM 80×80 не подойдет на сокеты Narrow ILM 94×56 и наоборот.
Если Square ILM признается компанией Intel как штатный разъем (в документации назван Regular), то Narrow ILM предназначен для высокоплотных систем, дающий возможность размещения большего количества слотов памяти и изменения охлаждающих потоков."
http://blog.servergid.ru/?p=286
И небольшая напоминалка: для 1-процессорных систем на лето 2012 актуален сокет 1155, для 2+ сокетных - 2011 с учётом того что выше. Остальные имеют смысл только для обновления или расширения парка с таким железом.
Если Square ILM признается компанией Intel как штатный разъем (в документации назван Regular), то Narrow ILM предназначен для высокоплотных систем, дающий возможность размещения большего количества слотов памяти и изменения охлаждающих потоков."
http://blog.servergid.ru/?p=286
И небольшая напоминалка: для 1-процессорных систем на лето 2012 актуален сокет 1155, для 2+ сокетных - 2011 с учётом того что выше. Остальные имеют смысл только для обновления или расширения парка с таким железом.
вторник, 10 июля 2012 г.
Обходим блокировку википедии
Если попытаться получить доступ "как обычно", получим уй. Впрочем, у них не заблокирована мобильная версия, которая доступна так: берётся нужный урл и между ru.wikipedia вписываем mobile, получив ru.mobile.wikipedia.org/...
понедельник, 9 июля 2012 г.
ssh: отключаем проверки отпечатка
Бывает нужно отключить проверку отпечатков, например внутри локалки, и особенно актуально для автоматических скриптов.
Вариант 1: ssh -o StrictHostKeyChecking=no host.ru
Оно же, без записи ключа в known_hosts: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru
Вариант 2: в ~/.ssh/config:
Вариант 1: ssh -o StrictHostKeyChecking=no host.ru
Оно же, без записи ключа в known_hosts: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru
Вариант 2: в ~/.ssh/config:
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
Подписаться на:
Сообщения (Atom)