Знай свой cgroup

Давеча столкнулся с непонятным (для меня до сегодня) поведением cgroup. Изначально описание проблемы было очень информативным “сервер тормозит”.

Захожу я на сервер и вижу картину маслом:

Куча свободной памяти, но сервер сидит в свопе и выбираться оттуда категорически не желает. Я последовательно начал перебирать все известные мне лимиты и ограничения: везде норм, хорошо и ничего не вызывает подозрений.

Так как эта нода кубернетеса, то я посмотрел и на ограничения подов в /sys/fs/cgroup/memory/. Тоже все согласно описанному, везде memory.limit_in_bytes соответствуют нужному.

Затем я скопипастил микроскрипт что бы посмотреть, кто занял своп

SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
    PID=`echo $DIR | cut -d / -f 3`
    PROGNAME=`ps -p $PID -o comm --no-headers`
    for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
    do
        let SUM=$SUM+$SWAP
    done
    if (( $SUM > 0 )); then
        echo "PID=$PID swapped $SUM KB ($PROGNAME)"
    fi
    let OVERALL=$OVERALL+$SUM
    SUM=0
done
echo "Overall swap used: $OVERALL KB"

Но скрипт выдал совершенно не совпадающие с системными утилитами значение. Согласно его выводу, своп использовался на 6 гигов. А я вижу на скриншоте выше – 12. Проверил выборочно значения из /proc – совпадают с высчитанными …

Ок, проверю вообще работу подсистему памяти. Набросал быстренько микропрограммку на С, которая раз в секунду сжирала гиг памяти. top честно показал сначала исчерпание free, потом окончание свопа. После пришел OOM и убил программку. Всё правильно, всё так и должно быть.

Долго я ломал голову и пробовал разные варианты. Пока в процессе очередного созерцания top внезапно глаз не зацепился за главного пожирателя памяти. Вернее за его показатель VIRT в 32 гига памяти. Так-то я смотрел на %MEM и RES. В общем, появился резонный вопрос “какого?”

Забрезжила идея, что что-то не так с cgroup. Ок, делаю группу с лимитом памяти в 10 гигов, проверяю, что memory.limit_in_bytes стоят, запускаю снова программку-пожиратель памяти … и вуаля! Через 10 секунд сожралось ровно 10 гигов RAM, и начал жраться своп. Вопрос “какого?” стал более актуальным

Начал гуглить. https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt говорит скромно

memory.memsw.usage_in_bytes # show current usage for memory+Swap (See 5.5 for details)

memory.limit_in_bytes # set/show limit of memory usage

memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage

Про memsw я специально добавил. Но на этой машине Ubuntu 20.04 с cgroup V2 и параметра с memsw нет. Нахожу дальнейшим гуглежом https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

The main argument for a combined memory+swap facility in the original cgroup design was that global or parental pressure would always be able to swap all anonymous memory of a child group, regardless of the child’s own (possibly untrusted) configuration. However, untrusted groups can sabotage swapping by other means – such as referencing its anonymous memory in a tight loop – and an admin can not assume full swappability when overcommitting untrusted jobs.

Особенно понравились слова про саботаж. То есть, докер ограничивал использование только RAM, но не SWAP. Теперь, когда проблема стала понятной, стало понятно, что и надо гуглить.

https://docs.docker.com/engine/install/linux-postinstall/#your-kernel-does-not-support-cgroup-swap-limit-capabilities

Грубо говоря, надо добавить в конфиг grub

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

Но тут нода “боевая”, надо дать доработать сервису, поэтому просто увеличили лимиты для пода.

Как говорится, все “побежало и поскакало”

PS Про то, что на ноде с k8s не должно быть свопа я в курсе. Как и то, что начиная с версии 1.21 он поддерживается.

Ресайз PV в k8s

Исходная ситуация: есть сервис, который использует PV, который необходимо увеличить. Примем, что другого (кроме стандартных утилит кубера) доступа к дискам нет от слова совсем.

В моем случае я увеличивал размер /data для prometheus.

Для начала запускаю копирование данных на локальную машину.

kubectl cp --container prometheus-server  prometheus-server-6966b574d7-5svfw:/data data/

Создаю новый диск и под к нему

$ cat pv.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/gce-pd
  name: prometheus-server-new
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
$ cat pod.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: prom-transfer-pod
spec:
  volumes:
    - name: storage
      persistentVolumeClaim:
       claimName: prometheus-server-new
  containers:
    - name: container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/data"
          name: storage
kubectl apply -f pv.yaml
kubectl apply -f pod.yaml

Теперь для ускорения заливки данных назад архивирую скачанное и заливаю назад

cd data
tar zcvf data.tar .
kubectl cp data.tar prom-transfer-pod:/data/

Заходим на под и распаковываем.

Теперь начинается самое интересное. Торможу сервис, не убивая его. Это необходимо, что бы pv перестал меняться.

kubectl scale deployment  prometheus-server  --replicas=0

Редактирую PV

kubectl edit pv pvc-6ef4e067-6012-11e8-a42f-42010a840193

Где меняю persistentVolumeReclaimPolicy на Retain. Это необходимо, что бы PV не удалился при удалении/изменении PVC.

Делаю полностью аналогичное для нового PV и удаляю новый же PVC. Теперь у меня есть старый и новый PV. Опять редактирую новый PV, на этот раз убивая секцию claimRef. Это “отцепит” новый PV от несуществующего уже PVC и разрешит его монтировать куда угодно.

Теперь можно заменить volumeName в старом PVC. Ну или тупо грохнуть и создать новый по образцу

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus-server
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
     requests:
       storage: 50Gi
  volumeName: pvc-bd24792e-785c-11e8-a42f-42010a840193

Все, после того, как PV сменит статус на Bound, можно запустить сервер назад

kubectl scale deployment  prometheus-server  --replicas=1

После проверки работоспособности старый PV можно удалить.

Новый датацентр. Сертификаты в почту

Для своих нужд я обычно ставлю Zimbra Open Source Edition. Простой, дуракоустойчивый почтовый сервер со всякими необходимыми плюшками. Но есть в нем одна маленькая проблема: по умолчанию он генерит самоподписанные сертификаты, на которые ругаются всякие почтовые клиенты. Значит, надо подсунуть сертификаты от letsencrypt

Сделаем на сервере каталог для сертификатов

mkdir -p /opt/zimbra/ssl/letsencrypt/
chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/

Опять же, маленький скриптик, который пускается руками после обновления сертификатов и проверки готовности всего ко всему. Он же zimbra_check

cat /opt/www/chain.pem >> /etc/letsencrypt/live/mail.ka12.co/fullchain.pem 
scp  /etc/letsencrypt/live/mail.ka12.co/* root@mail:/opt/zimbra/ssl/letsencrypt/
ssh root@mail "chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"

Логика понятна из текста: добавляем CA ключ (отсюда) в цепочку, копируем все это в потроха зимбры и проверяем, согласится ли она это съесть. Обычно ответ “да”, но иногда она взбрыкивает и надо смотреть, чего же ей не нравится. Если ошибок нет, то можно запустить zimbra_deploy

#!/bin/bash
ssh root@mail "runuser -l zimbra -c 'zmcontrol stop'"
ssh root@mail "cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.`date \"+%Y%m%d\"`"
ssh root@mail "runuser -u zimbra cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"
ssh root@mail "runuser -l zimbra -c '/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem'"
ssh root@mail "runuser -l zimbra -c 'zmcontrol start'"

Он тормозит нафиг всю зимбру, бекапит и деплоит сертификаты и снова запускает все назад.

Новый датацентр. Докер

Следующим большим шагом в постройке “датацентра” у меня будет разворачивание докера. Без него нынче никуда, да и удобный он, зараза.

Согласно всем мануалам для новичков, для минимально живучего кластера необходимо заиметь три машины. А у меня одна, но зато физическая. Значит, поднимаю три виртуалки и туда запихиваю докер.

Но три виртуалки – это уже не одна. Требуется автоматизация. Вариантов много – от правки кикстарт файлов до клонирования уже существующих машин. Но тут я решил пойти другим путем, более простым в случае использования KVM

Добываю/делаю правильный ifcfg фаил

cat ifcfg-eth0
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="172.16.100.11"
PREFIX="24"
GATEWAY="172.16.100.1"
NM_CONTROLLED="no"

Добавляю пароль рута в файл root_pass и кладу рядом свой публичный ключ. Рядом же resolv.conf. Затем создаю образ диска

virt-builder centos-7.4 --arch amd64 -o docker1.ka12.co.img --size 80G --format qcow2 --hostname docker1.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc

И запускаю машину с ним.

virt-install --name docker1.ka12.co --network bridge=virbr100 --memory 8096 --disk path=docker1.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

Минута и виртуалка готова. Меняем ip адрес в конфиге+хостнейм и повторяем так еще два раза. Все, ноды для кластера готовы.

Добавляем их в инвентори и бутсрапим до приемлемого состояния.

ansible-playbook -i inventory -l docker* centos-bootstrap.yml

Делать еще один плейбук лень, поэтому просто прохожу по хостам с командой

yum -y install freeipa-client && ipa-client-install --mkhomedir

ansible-playbook -i inventory docker-install.yml

И на любой машине проверяю, что докер докерит

docker run hello-world

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

На хосте:

mkdir -p /opt/nfs
chmod 777 /opt/nfs
cat /etc/exports
/opt/nfs 172.16.0.0/16(rw,sync,no_root_squash,no_all_squash)
systemctl restart nfs-server

Проверяю, что увидит докер

# showmount -e 172.16.100.1
Export list for 172.16.100.1:
/opt/nfs 172.16.0.0/16

Создаю супер-каталог для volume

mkdir -p /opt/nfs/data
chmod 777 /opt/nfs/data

Теперь на докер-хосте создаю volume


docker volume create --driver local --opt type=nfs --opt o=addr=172.16.100.1,rw --opt device=:/opt/nfs/data --name data

И проверяю

[root@docker1 ~]# docker volume ls
DRIVER VOLUME NAME
local data
[root@docker1 ~]# docker volume inspect data
[
{
"CreatedAt": "2018-01-27T08:46:56-05:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/data/_data",
"Name": "data",
"Options": {
"device": ":/opt/nfs/data",
"o": "addr=172.16.100.1,rw",
"type": "nfs"
},
"Scope": "local"
}
]

Теперь проверяю, как с этим будут работать контейнеры

docker container run -ti -v data:/data alpine sh

Там в /data можно посоздавать файлики и вообще поиграться “как будто в реальной жизни”.

Бекапы – фигня. Восстановление – вот это да!

Пару дней назад все и везде прожужжали мантры про всемирный день бекапа и про то, что делать бекапы – это хорошо. Но почему-то никто нигде не жужжит про то, что бекапы сами по себе, без восстановления – фигня полная. Ну лежит где-то резервная копия, место занимает. И что вы с ней будете делать, если что-то случится? А как до неё доберетесь? А ключи и пароли откуда возьмете? И для любой системы таких вопросов можно задать сотни.

Будь готов!

Именно поэтому я изобрел лично для себя свой личный DIRT (Disaster Recovery Test). Где-то раз в месяц (или чаще, под настроение) я тупо сношу все с ноута и ставлю заново операционку и накатываю назад рабочее окружение. Первые разы длились все выходные и без потерь не обходилось. Зато сейчас мне требуется примерно час, что бы вернуться в строй. Около трех часов – что бы вернуть 100% окружения назад. Быстрее не получается, ибо ограничен скоростью ноутбука и интернета. Максимальные потери – с начала рабочего дня. Все, что мне необходимо на данный момент – это ноутбук и быстрый интернет.

Итак, что необходимо для получения аналогичного?

Во-первых, компьютер с нормальной и привычной вам инфраструктурой. Представьте себя в командировке в далеком городе. У вас сгорает синим пламенем ваш любимый ноутбук. Что делать? Лучшее решение: тупо идем в ближайший компьютерный магазин и покупаем новый ноутбук. Попытка ремонта или привоза “трупика” домой – все это потери времени, а его обычно всегда не хватает. Мой выбор на данный момент – MacBook. Просто, удобно и unix внутри.

Во-вторых, приучите себя использовать систему хранения паролей. Все пароли, ключи, сертификаты или конфигурационные файлы должны быть там. Все, что необходимо вам помнить – это как добраться до этой системы и мастер-пароль. В свое время я выбрал 1Password и ни капельки об этом не пожалел за 5 лет.

В-третьих, приучите себя использовать системы контроля версий. SVN, Git, Mercurial – что угодно, но в этой системе должны лежать все документы и файлы, которые представляют для вас хоть какую-то ценность. Да, поначалу будет тяжело, особенно если вы не представитель ИТшной области. Очень ограниченным паллиативом будет покупка аккаунта в дропбоксе или в другом хранилище файлов. Там тоже появляются возможности про сохранение версий документов и их “отката” при необходимости.

Так же очень полезно завести на каком-нибудь облачном хранилище файлов каталог, в который вы будете складывать дистрибутивы программ. Да, сейчас есть много магазинов приложений (например, встроенный в Apple или Steam. Что-то аналогичное есть у Windows), который после ввода заветного логина и пароля дадут поставить вам все назад. Но до сих пор есть куча приложений, авторы которых по каким-то причинам не могут или не хотят публиковаться в таких магазинах.

И когда вам потребуется поставить такое приложение, то легко можно столкнуться со следующими проблемами:

– Нужной версии уже нет. А доступная версия требует покупки. Да, можно списаться с автором или поискать в интернете, но это потеря времени.
– Для скачивания версии необходимо зарегистрироваться/залогиниться на сайте, потом они пришлют ссылку, по которой скачается “качальщик”, который и начнет скачивать нужное.
– Дистрибутив большой или лежит на медленных серверах. Пока скачаешь …

Наличие своего, персонального архива нивелирует эти проблемы практически одним махом.

И вот только после этого можно поставить какую-нибудь систему резервного копирования (Acronis Backup очень даже, не смотря на мелкие глюки). И натравить её на всё вот это скопом для создания последней “линии обороны”.

Ну и регулярно проводить восстановления накопленного непосильным трудом. Повторюсь, в первые разы вы обязательно что-нибудь потеряете или забудете и это нормально. Еще раз – абсолютно нормально. Это для того и надо, что бы когда это случилось внезапно, у вас был четкий план, что и когда делать.

Вот как у меня происходило это в последний и предпоследний раз (я пролил кофе на ноутбук и просто захотелось)

1. Сносим диск и ставим операционку с нуля.
2. Как только она поставилась, идем в родной магазин приложений и ставим хранилку паролей. Затем клиент для “облачных облаков”.
3. Запускаем все это. Доступ до паролей получен, основные файлы (типа инсталлятора vpn) пошли заливаться на ноутбук.
4. Запускаем установку необходимого из Apple store. Всякие slack, things и прочее.
5. По мере установки всего я уже могу начинать пользоваться ноутбуком. Да, почта не вся засинхронизировалась или индексатор не прошел по всем файлам, но я уже могу что-то делать.
6. Восстанавливаем из системы контроля версий последние проекты и разворачиваем файлы конфигурации.
7. По мере необходимости ставим тот софт, который не требуется “прямо сейчас”, но нужен регулярно.
8. Оцениваем потери и думаем над шагами, которые надо сделать, что бы это не повторилось.

Все. Первый раз сложно, в 10й – просто. Главное тут – регулярность.

Пробую ATI 2017 на зуб. День 1. Бэкап …

Зачем нужно резервное копирование, если сейчас все можно хранить в облаках? Ответ простой: облака обеспечивают доступность, а резервное копирование – сохранность. Толку иметь доступ к облаку, если до этого из них удалил самый нужный на текущий момент файл? Да, некоторые облачные провайдеры дают “хранение 5ти последних копий”, но в реальности от этого смысла мало: при регулярном сохранении файла эти 5 копий исчерпывают себя в течении часа.

Конечно, есть и встроенные решения в современные операционные системы (та же Time Machine в OS X), но они сделаны по остаточному принципу. Кому-то везет, но лично у меня с ними больше проблем, чем радости. Поэтому я решил взять и пощупать Acronis True Image 2017. По уверениям рекламы самый-самый, сохраняет быстро, а восстанавливает еще быстрее.

Что самое важное в резервном копировании? Две вещи: скопировать нужное и дать доступ до нужного после “того случая”. Все остальное – пыль и тлен.

Ок, берем триальный Acronis True Image и ставим на ноутбук и телефон. Процесс установки ничем оригинальным не блещет (и это хорошо), поэтому описание пропускаю.

После запуска предложили выкинуть то, что в “облаках”.

ati01-01

Но почему не предложили исключить из бекапа программы? С одной стороны, будет уверенность, что после восстановления у меня будут именно те версии, с которыми я работал, а с другой – смысл мне бекапить Microsoft Office? Недочет? Недосмотр? Дизайнерский вывих?

Ну ладно, снимаю-ставлю галочки и запускаю первоначальный процесс резервного копирования. Копирование идет далеко не быстро, это минус.

ati01-02

А вот то, что процессор и диск при этом не перегружены и ноутбуком можно пользоваться без завываний вентилятора системы охлаждения – это плюс.

ati01-03

Оставляю копироваться ноутбук и беру в руки мобильный телефон, отмечаю все галочками …

ati01-04

Засекаю, сколько будет идти полное копирование телефона и сколько есть сейчас батарейки …

ati01-05

и фиксирую окончание

ati01-06

45 минут и и 6% батарейки на Samsung Galaxy S6. Не знаю как вам, но по-моему очень хорошо.

(пропущена ночь)

Дожидаюсь, когда на веб-панели мне сообщат, что всё отлично, все забекаплено и вообще шикарно.

ati01-09

Что в следующем шаге? А в следующем шаге обычная работа и утеря чего-либо очень-очень важного для меня.

На роль важного в мобильном телефоне выступит спам от МГТС. Делаю скрин на память.

ati01-08

А на роль очень важного на десктопе выступит скриншот из игры Elite:Dangerous. Название файла space_is_beatiful.jpg и он расположен прямо в моем домашнем каталоге.

ati01-10

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

Теперь ждем завтрашнего дня, когда я внезапно обнаружу, что кто-то (ну не я же, правда?) удалил эти важные частички моей цифровой жизни. Восстановить не получится, ибо в процессе работы место на диске и в телефоне перетерто уже много раз. Но это будет завтра.

Игрища с сервером – 3 или openvpn и ipv6

Сделав очередной openvpn сервер, я задался вопросом: а нафига я его вообще делал? Нет, что бы добираться безопасно до своих ресурсов, это да. Но одна из главных задач – дать клиенту ipv6 в мире ipv4. И именно её он не выполняет. Значит сейчас починим.

Самый простой вариант “в лоб” – перевести сервер в бридж режим и пусть клиенты будут представляться хост-машине как еще одни виртуалки. Минус – замучаюсь с безопасностью. Плюс – тупо и надежно.

Вариант посложнее – выпилить кусочек ipv6 сети и давать её клиентам. Минус тут один – некоторые клиенты почему-то желают видеть у себя /64 и никак иначе. А у меня всего одна /64. Нет, можно получить еще через любого туннельного брокера, но не хочу.

Значит вариант остается один: взять приватную ipv6 подсеть и сделать раздачу из него. Для выбора сетки мы можем брать все что нам понравится, главное что бы первый байт адреса был fd. Вот тут можно даже побаловаться, просто обновляя страничку.

Я возьму для своих крамольных целей сеть fdab:cdef:1234:5678::/64

Почитав маны, добавляю следующие строчки в конфиг сервера

server-ipv6 fdab:cdef:1234:5678::/64
tun-ipv6
push tun-ipv6

И перезагружаю сервер

systemctl restart openvpn@server.service

Переподключаю клиента и смотрю в логи. Вижу заветную строку.

Fri Jan 29 03:12:31 2016 /usr/sbin/ip addr add dev tun0 local 10.100.2.6 peer 10.100.2.5
Fri Jan 29 03:12:31 2016 /usr/sbin/ip -6 addr add fdab:cdef:1234:5678::1000/64 dev tun0
Fri Jan 29 03:12:31 2016 /usr/sbin/ip route add 10.100.0.0/24 via 10.100.2.5

Пробую с клиента пингануть сервер

$ ping6 fdab:cdef:1234:5678::1 -c 2
PING fdab:cdef:1234:5678::1(fdab:cdef:1234:5678::1) 56 data bytes
64 bytes from fdab:cdef:1234:5678::1: icmp_seq=1 ttl=64 time=48.1 ms
64 bytes from fdab:cdef:1234:5678::1: icmp_seq=2 ttl=64 time=48.2 ms

Работает! Теперь осталось самая мелочь – запушить правило роутинга, адрес ДНС и собственно роутинг сделать.

Строчка конфига

push "route-ipv6 2000::/3"

Заставит маршрутизировать весь ipv6 трафик через openvpn. Почти как redirect-gateway def1, но только для ipv6.

Но так как у нас приватная сеть, то я могу пинговать только openvpn. Другие хосты согласно правилам хорошего тона, такие поползновения обламывают.

К сожалению, тут опять на белый свет выползает firewalld, а вернее его хипстерские правила, которые не умеют ничего, кроме открытия и закрытия портов. Выносим его

systemctl stop firewalld
yum -y install iptables-services
systemctl enable iptables
systemctl enable ip6tables
systemctl start iptables
systemctl start ip6tables

Добавляем правила для SNAT и открываем 1194/udp на вход
-A POSTROUTING -s 10.100.2.0/24 -o eth0 -j SNAT --to-source 10.100.0.133
-A POSTROUTING -s fdab:cdef:1234:5678::/64 -o eth0 -j SNAT --to-source 2a01:4f8:171:1a43:5054:ff:fe0d:da49

-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT

И удаляем мешающееся

-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Теперь последний шаг – sysctl.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding=1

То, что надо перечитать – перечитываем, то, что надо перезагрузить – перезагружаем.

Если все сделано правильно, клиент VPN начнет пинговать внешние ipv6 ресурсы. traceroute у меня почему-то обламывался на первом же хопе. Посмотрел tcpdump – видимо, не до конца допилили модуль, отвечающий за NAT: адреса не переписываются. Но с другой стороны – ну и пофиг: если очень надо, то я смогу зайти прямо на хост.

Последняя проверка: а файлики-то клиент утащит?

$ wget -6 google.com
--2016-01-29 04:07:49-- http://google.com/
Resolving google.com (google.com)... 2607:f8b0:4005:800::1002
Connecting to google.com (google.com)|2607:f8b0:4005:800::1002|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.de/?gfe_rd=cr&ei=5SurVtbrKeaD8Qeu6YvACw [following]
--2016-01-29 04:07:49-- http://www.google.de/?gfe_rd=cr&ei=5SurVtbrKeaD8Qeu6YvACw
Resolving www.google.de (www.google.de)... 2607:f8b0:4010:800::101f
Connecting to www.google.de (www.google.de)|2607:f8b0:4010:800::101f|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

[ <=> ] 19,066 97.8KB/s in 0.2s

2016-01-29 04:07:50 (97.8 KB/s) - ‘index.html’ saved [19066]

Утащил!

Значит, можно удовлетворенно потирать руки и идти спать

Игрища с сервером – 2 (openvpn, ssh и freeipa)

Наконец-то можно приступить к самому приятному: выбиванию окон во внешний мир. Или VPN. Ответы на вопросы зачем, почему и куда оставлю за рамками. Мне надо и все тут. Для организации канала буду использовать широко известный openvpn.

Ставим удобности.

yum -y install epel-release mc

Для начала подниму для проверки просто сервер. Без каких-либо излишеств.

yum -y install openvpn easy-rsa
cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn
mcedit /etc/openvpn/server.conf

Конфиг после удаления лишнего получился примерно такой

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.100.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.100.0.0 255.255.255.0"
;push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.100.0.10"
push "dhcp-option DOMAIN local.multik.org"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
verb 3

Полностью по мануалу, без каких-либо отклонений. Значение каждой строчки можно посмотреть в документации.

Теперь ключи. Опять же, не отходя от канонов.

mkdir -p /etc/openvpn/easy-rsa/keys
cp -rf /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa
mcedit /etc/openvpn/easy-rsa/vars

Тут я поправил строки “по умолчанию”

export KEY_COUNTRY="RU"
export KEY_PROVINCE="RU"
export KEY_CITY="Moscow"
export KEY_ORG="VseMoe"
export KEY_EMAIL="multik@multik.org"
export KEY_OU="Internet"
...
export KEY_NAME="Server"
...
export KEY_CN="vpn.vsemoe.com"

Дальше просто лог команд, везде давим Enter.

cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
cd /etc/openvpn/easy-rsa/keys
cp dh2048.pem ca.crt server.crt server.key /etc/openvpn
cd /etc/openvpn/easy-rsa
./build-key client

Разрешаем форвард

mcedit /etc/sysctl.conf
net.ipv4.ip_forward = 1
sysctl -p

И стартуем сервер

systemctl enable openvpn@server.service
systemctl start openvpn@server.service

Теперь на хосте надо открыть порт 1194/udp и перебросить его на виртуалку с openvpn

-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
-A PREROUTING -d 136.243.151.196/32 -i eth0 -p udp --dport 1194 -j DNAT --to-destination 10.100.0.133

И на самой виртуалке открыть тем или иным образом порт

firewall-cmd --add-service=openvpn --permanent
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload

Теперь перетаскиваем на клиента все client* файлы и ca.crt и делаем конфиг (обычный текстовый файл)

client
dev tun
proto udp
remote 136.243.151.196 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
ca ca.crt
cert client.crt
key client.key

Пробуем соедениться

$ sudo openvpn --config confif.vpn
Wed Jan 27 03:55:22 2016 OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Wed Jan 27 03:55:22 2016 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
Wed Jan 27 03:55:22 2016 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Jan 27 03:55:22 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Wed Jan 27 03:55:22 2016 UDPv4 link local: [undef]
Wed Jan 27 03:55:22 2016 UDPv4 link remote: [AF_INET]136.243.151.196:1194
Wed Jan 27 03:55:22 2016 TLS: Initial packet from [AF_INET]136.243.151.196:1194, sid=3dd59a35 34ce24da
Wed Jan 27 03:55:22 2016 VERIFY OK: depth=1, C=RU, ST=RU, L=Moscow, O=VseMoe, OU=Internet, CN=vpn.vsemoe.com, name=Server, emailAddress=multik@multik.org
Wed Jan 27 03:55:22 2016 VERIFY OK: depth=0, C=RU, ST=RU, L=Moscow, O=VseMoe, OU=Internet, CN=server, name=Server, emailAddress=multik@multik.org
Wed Jan 27 03:55:23 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 27 03:55:23 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 27 03:55:23 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 27 03:55:23 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 27 03:55:23 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Jan 27 03:55:23 2016 [server] Peer Connection Initiated with [AF_INET]136.243.151.196:1194
Wed Jan 27 03:55:25 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jan 27 03:55:25 2016 PUSH: Received control message: 'PUSH_REPLY,route 10.100.0.0 255.255.255.0,dhcp-option DNS 10.100.0.10,route 10.100.2.1,topology net30,ping 10,ping-restart 120,ifconfig 10.100.2.14 10.100.2.13'
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: route options modified
Wed Jan 27 03:55:25 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Jan 27 03:55:25 2016 ROUTE_GATEWAY 172.16.137.2/255.255.255.0 IFACE=eno16777736 HWADDR=00:0c:29:fa:0a:54
Wed Jan 27 03:55:25 2016 TUN/TAP device tun1 opened
Wed Jan 27 03:55:25 2016 TUN/TAP TX queue length set to 100
Wed Jan 27 03:55:25 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jan 27 03:55:25 2016 /usr/sbin/ip link set dev tun1 up mtu 1500
Wed Jan 27 03:55:25 2016 /usr/sbin/ip addr add dev tun1 local 10.100.2.14 peer 10.100.2.13
Wed Jan 27 03:55:25 2016 /usr/sbin/ip route add 10.100.0.0/24 via 10.100.2.13
Wed Jan 27 03:55:25 2016 /usr/sbin/ip route add 10.100.2.1/32 via 10.100.2.13
Wed Jan 27 03:55:25 2016 Initialization Sequence Completed

Как видно по последней строчке, соединение установилось. Пробуем добраться до любого хоста “внутри” сети.

$ ssh root@10.100.0.10
ssh: connect to host 10.100.0.10 port 22: No route to host

Облом. По простой причине – ничего в сети 10.100.0 не знает про сеть 10.100.2, которую я отдал под VPN. Самое простое решение – включить маскарадинг на выходе

firewall-cmd --permanent --add-masquerade
firewall-cmd --reload

Пробую еще раз

$ ssh root@10.100.0.10
The authenticity of host '10.100.0.10 (10.100.0.10)' can't be established.
ECDSA key fingerprint is fb:c1:72:a2:9a:a1:df:f5:d0:95:09:a4:3b:2e:9d:68.

Сработало. Это хорошо. Теперь немного добавим безопасности путем добавление пре-авторизационного ключа. Опять же, по мануалу

openvpn --genkey --secret ta.key
tls-auth ta.key 0

В принципе, тут можно остановиться. Сервер работает, создаешь по ключу на клиента и вперед. Но мне так не охота. Я хочу сделать так, что бы конфигурационный файл был у всех одинаковый, а пользователи авторизовались по классическому логину и паролю. А логины и пароли брались бы из FreeIPA.

Опять же, вариантов много. Самый распространенный – это использование freeipa как ldap сервера. Мне лично лень. Я решил воспользоваться вариантом, когда freeipa авторизует пользователей в системе (так как это стандартный способ), а openvpn авторизовать уже через пользователей в системе.

Ставим на vpn все необходимое и подключаемся к ипе (подробности в ранних постах).

yum install -y ipa-client
ipa-client-install --mkhomedir

И тут оно обламывается. По простой причине – для vpn.local.multik.org нет адреса в базе. А у машины два локальных интерфейса и какой использовать для чего – непонятно.

Идем в виртуалку с ipa и добавляем

[root@ipa ~]# kinit admin
Password for admin@LOCAL.MULTIK.ORG:
[root@ipa ~]# ipa dnsrecord-add
Record name: vpn
Zone name: local.multik.org
Please choose a type of DNS resource record to be added
The most common types for this type of zone are: A, AAAA

DNS resource record type: A
A IP Address: 10.100.0.133
Record name: vpn
A record: 10.100.0.133

И снова пробуем – теперь все получится.

Теперь небольшой трюк. Что бы не давать по умолчанию доступ до VPN всем, я создам новый “сервис”.

cd /etc/pam.d/
ln -s system-auth openvpn

Теперь Осталось мелочь – создать в ипе HBAC сервис openvpn и установить правила. Создаем сервис, группу для него и соединяем вместе

[root@ipa ~]# ipa hbacsvc-add openvpn
----------------------------
Added HBAC service "openvpn"
----------------------------
Service name: openvpn

[root@ipa ~]# ipa hbacrule-add allow_openvpn
-------------------------------
Added HBAC rule "allow_openvpn"
-------------------------------
Rule name: allow_openvpn
Enabled: TRUE

[root@ipa ~]# ipa hbacrule-add-service allow_openvpn --hbacsvcs=openvpn
Rule name: allow_openvpn
Enabled: TRUE
Services: openvpn
-------------------------
Number of members added 1
-------------------------

Проверяю, что натворил.

[root@ipa ~]# ipa hbacrule-find allow_openvpn
-------------------
1 HBAC rule matched
-------------------
Rule name: allow_openvpn
Enabled: TRUE
Services: openvpn
----------------------------
Number of entries returned 1
----------------------------

Добавляю к правилу пользователя и хост

[root@ipa ~]# ipa hbacrule-add-user allow_openvpn --user=multik
Rule name: allow_openvpn
Enabled: TRUE
Users: multik
Services: openvpn
-------------------------
Number of members added 1
-------------------------

[root@ipa ~]# ipa hbacrule-add-host allow_openvpn --hosts=vpn.local.multik.org
Rule name: allow_openvpn
Enabled: TRUE
Users: multik
Hosts: vpn.local.multik.org
Services: openvpn
-------------------------
Number of members added 1
-------------------------

Проверяю, что сработает на меня и на админа (который вроде как и не должен иметь доступ)

[root@ipa ~]# ipa hbactest --user=admin --host=vpn.local.multik.org --service=openvpn
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Not matched rules: allow_openvpn

[root@ipa ~]# ipa hbactest --user=multik --host=vpn.local.multik.org --service=openvpn
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Matched rules: allow_openvpn

Как вижу, в системе есть правило по умолчанию, которое дает доступ всем до всего. Но если его просто выкусить, то я тупо лишусь доступа И по ssh тоже. Поэтому надо сделать аналогичное для ssh

[root@ipa pam.d]# cd
[root@ipa ~]# ipa hbacsvc-add sshd
ipa: ERROR: HBAC service with name "sshd" already exists

Опс, сервис такой уже по умолчанию есть. Ну пойду дальше

[root@ipa ~]# ipa hbacrule-add allow_sshd
----------------------------
Added HBAC rule "allow_sshd"
----------------------------
Rule name: allow_sshd
Enabled: TRUE
[root@ipa ~]# ipa hbacrule-add-service allow_sshd --hbacsvcs=sshd
Rule name: allow_sshd
Enabled: TRUE
Services: sshd
-------------------------
Number of members added 1
-------------------------
[root@ipa ~]#

ipa hbacrule-add-user allow_sshd --user=multik
ipa hbacrule-add-host allow_sshd --hosts=vpn.local.multik.org

Проверяю

[root@ipa ~]# ipa hbactest --user=admin --host=vpn.local.multik.org --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Not matched rules: allow_openvpn
Not matched rules: allow_sshd
[root@ipa ~]# ipa hbactest --user=multik --host=vpn.local.multik.org --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Matched rules: allow_sshd
Not matched rules: allow_openvpn

Все на месте. Выкусываю нафиг
[root@ipa ~]# ipa hbacrule-disable allow_all
------------------------------
Disabled HBAC rule "allow_all"
------------------------------

Согласно выводу выше, я теперь не могу залогиниться на хост vsemoe-com пользователем multik.

[root@ipa ~]# ssh multik@vsemoe-com
multik@vsemoe-com's password:
Connection closed by UNKNOWN

Не соврала система. “Не пущаит”. Проверяю почему

[root@ipa ~]# ipa hbactest --user=multik --host=vsemoe-com.local.multik.org --service=sshd
---------------------
Access granted: False
---------------------
Not matched rules: allow_openvpn
Not matched rules: allow_sshd

Добавляю хост, как разрешенный к коннекту на него по ssh

[root@ipa ~]# ipa hbacrule-add-host allow_sshd --hosts=vsemoe-com.local.multik.org
Rule name: allow_sshd
Enabled: TRUE
Users: multik
Hosts: vpn.local.multik.org, vsemoe-com.local.multik.org
Services: sshd
-------------------------
Number of members added 1
-------------------------

Будет пускать?

[root@ipa ~]# ipa hbactest --user=multik --host=vsemoe-com.local.multik.org --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_sshd
Not matched rules: allow_openvpn

Должно. Проверяю

[root@ipa ~]# ssh multik@vsemoe-com
multik@vsemoe-com's password:
Last failed login: Thu Jan 28 12:53:43 MSK 2016 from 2a01:4f8:171:1a43:5054:ff:fea4:8c6 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Mon Jan 25 16:51:46 2016 from 10.100.0.254

Как говорится, работает. Теперь последняя проверка: пустит ли пользователя multik на хосте vpn для сервиса openvpn?

[root@ipa ~]# ipa hbactest --user=multik --host=vpn.local.multik.org --service=openvpn
--------------------
Access granted: True
--------------------
Matched rules: allow_openvpn
Not matched rules: allow_sshd

Для vpn пустит, а по ssh не пустит. Теперь остались сущие мелочи. Добавялем в конфиг сервера

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

а в конфиг клиента

auth-user-pass

и пробуем

$ sudo openvpn --config confif.vpn
Thu Jan 28 04:57:42 2016 OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Thu Jan 28 04:57:42 2016 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
Enter Auth Username: ******
Enter Auth Password: ***********

Как видим, спросило логин и пароль. И дальше как обычно. Но каждый раз вводить логин и пароль лень. Всякие ViscoCity и прочие умеют это. Научим и консольного клиента.

Сделаем обычный текстовый файлик из 2х строчек: логина и пароля. И укажем его имя сразу после auth-user-pass. Если все сделано правильно, то openvpn ничего не будет спрашивать, а просто возьмет и прицепится.

Теоретически, на этом можно и закончить процесс. Но некрасиво как-то. “Клиентами” моего сервиса будут люди, далекие от техники. Дизайнеры всякие и менеджеры. Пока им объяснишь, чего куда совать и на что нажимать …

Технология очень простая. Берем исходный конфиг для клиента, и добавляем к нему следующие строки

key-direction 1

<ca>
—–BEGIN CERTIFICATE—–
ca.crt
—–END CERTIFICATE—–
</ca>

<cert>
—–BEGIN CERTIFICATE—–
client.crt
—–END CERTIFICATE—–
</cert>

<key>
—–BEGIN PRIVATE KEY—–
client.key
—–END PRIVATE KEY—–
</key>

<tls-auth>
—–BEGIN OpenVPN Static key V1—–
ta.key
—–END OpenVPN Static key V1—–
</tls-auth>

Внутрь просто копируем содержимое соответствующих файлов. Любым текстовым редактором. Ну и убираем строки

ca ca.crt
cert client.crt
key client.key

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

Всё. Я получил в свое распоряжение VPN сервер. Управляемый хоть из консоли, хоть из веб-морды (как? я не писал? сходите браузером на адрес ipa сервера). Ну вообще-то не только VPN сервер, но в этой рассказке я писал только про VPN.

Удачи!

Игрища с сервером – 1

Или даешь централизацию! Сервер установлен, некоторые виртуалки перенесены, а некоторые удалены. Надо облегчать себе жизнь.

Уже сейчас на хосте размещено с десяток виртуалок. И уже сейчас всеми ими рулить скучно. Зашел на одну, обновил, сходил на другую, обновил. А пароли поменять? А дать доступ очередному фрилансеру и потом не забыть его отобрать? В общем, тяжело. Было.

Первым делом надо поставить единую систему авторизации. Что бы все пароли были в одном месте и думать не надо было. Так как основной системой везде у меня CentOS, то самым логичным кандидатом на эту тему становится FreeIPA.

Раньше я на нее взглянуть без слез не мог, а теперь она выросла во вполне себе крутую систему, умеющую все, что необходимо системам такого рода. Начнем. Этап установки еще одной виртуалки я пропускаю.

yum -y install ipa-server bind bind-dyndb-ldap ipa-server-dns
ipa-server-install --setup-dns --mkhomedir

Если что-то где-то накосячили (а вы в первый раз обязательно накосячите), то всегда можно убрать все в первоначальное состояние.
ipa-server-install --uninstall

В процессе установки у меня спросили два пароля – самого главного и админа. Плюс отказался от dns-forwarders (ибо пока в них смысла нет, но если надо, то потом можно поставить), а дальше просто соглашался со всем. Как увидите бегущие пунктики – значит вы прорвались и скоро получите настроенную систему.

Итак, оно вроде сказало, что готово. Чего делаем? Первым делом – сделаем, что бы у пользователей по умолчанию был шелл /bin/bash, а не /bin/sh.

kinit admin
ipa config-mod --defaultshell=/bin/bash

И добавлю себя любимого

# ipa user-add
First name: Viacheslav
Last name: Kaloshin
User login [vkaloshin]: multik
-------------------
Added user "multik"
-------------------
User login: multik
First name: Viacheslav
Last name: Kaloshin
Full name: Viacheslav Kaloshin
Display name: Viacheslav Kaloshin
Initials: VK
Home directory: /home/multik
GECOS: Viacheslav Kaloshin
Login shell: /bin/bash
Kerberos principal: multik@LOCAL.MULTIK.ORG
Email address: multik@local.multik.org
UID: 1624000001
GID: 1624000001
Password: False
Member of groups: ipausers
Kerberos keys available: False

и поменяем пароль мне (в принципе можно было это сделать и сразу, но так интересней)

# ipa user-mod multik --password
Password:
Enter Password again to verify:
----------------------
Modified user "multik"
----------------------
User login: multik
First name: Viacheslav
Last name: Kaloshin
Home directory: /home/multik
Login shell: /bin/bash
Email address: multik@local.multik.org
UID: 1624000001
GID: 1624000001
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: True

Теперь в принципе можно проверить, залогинившись на хост свежесозданным пользователем

# ssh multik@10.100.0.10
multik@10.100.0.10's password:
Password expired. Change your password now.
Creating home directory for multik.
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user multik.
Current Password:
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Connection to 10.100.0.10 closed.

Как видим, система принудительно заставляет пользователя сменить пароль. Это хорошо.

В принципе, можно все необходимое делать из консоли, а можно и с веб-интерфейса – просто браузером сходите и все сами увидите.

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

на виртуалке:

# cat /etc/resolv.conf
search local.multik.org
nameserver 10.100.0.10
nameserver 10.100.0.254

на ipa надо открыть днс:

firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload

и опять на виртуалке

# ping ipa -c 2
PING ipa.local.multik.org (10.100.0.10) 56(84) bytes of data.
64 bytes from ipa.local.multik.org (10.100.0.10): icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from ipa.local.multik.org (10.100.0.10): icmp_seq=2 ttl=64 time=0.461 ms

--- ipa.local.multik.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.344/0.402/0.461/0.061 ms

Отлично. Теперь подключим виртуалку

На ipa

firewall-cmd --permanent --add-service={ntp,http,https,ldap,ldaps,kerberos,kpasswd}
firewall-cmd --reload

на виртуалке

yum install -y ipa-client
# ipa-client-install --mkhomedir
Discovery was successful!
Client hostname: vsemoe-com.local.multik.org
Realm: LOCAL.MULTIK.ORG
DNS Domain: local.multik.org
IPA Server: ipa.local.multik.org
BaseDN: dc=local,dc=multik,dc=org

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
Attempting to sync time using ntpd. Will timeout after 15 seconds
User authorized to enroll computers: admin
Password for admin@LOCAL.MULTIK.ORG:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=LOCAL.MULTIK.ORG
Issuer: CN=Certificate Authority,O=LOCAL.MULTIK.ORG
Valid From: Mon Jan 25 12:03:20 2016 UTC
Valid Until: Fri Jan 25 12:03:20 2036 UTC

Enrolled in IPA realm LOCAL.MULTIK.ORG
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm LOCAL.MULTIK.ORG
trying https://ipa.local.multik.org/ipa/json
Forwarding 'ping' to json server 'https://ipa.local.multik.org/ipa/json'
Forwarding 'ca_is_enabled' to json server 'https://ipa.local.multik.org/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (vsemoe-com.local.multik.org) does not have A/AAAA record.
Missing reverse record(s) for address(es): 10.100.0.178, 2a01:4f8:171:1a43:5054:ff:fe51:f70e.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Forwarding 'host_mod' to json server 'https://ipa.local.multik.org/ipa/json'
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring local.multik.org as NIS domain.
Client configuration complete.

При этом процессе, сразу создадутся и прямые записи в днс. Почему и как создавать сразу и обратные – я не разбирался.

[root@ipa ~]# host vsemoe-com
vsemoe-com.local.multik.org has address 10.100.0.178
vsemoe-com.local.multik.org has IPv6 address 2a01:4f8:171:1a43:5054:ff:fe51:f70e

Проверяю, как оно работает

[root@tower ~]# ssh multik@10.100.0.178
multik@10.100.0.178's password:
Creating home directory for multik.
[multik@vsemoe-com ~]$ whoami
multik
[multik@vsemoe-com ~]$ id
uid=1624000001(multik) gid=1624000001(multik) groups=1624000001(multik) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

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

Новый сервер с игрищами и блудницами – 4

Прошлый раз я закончил на том что мне удалось завести сертификат для vsemoe.com. Вручную, но тем не менее. Но доменчиков у меня целая куча и руками для них запрашивать сертификаты каждые три месяца … я слишком ленивый для этого. Да и интернет предлагает разные варианты решения этой проблемы.

Первым делом конфигурирую домены vsemoe.org и kaloshina.com аналогично vsemoe.com

bash-3.2$ host vsemoe.com
vsemoe.com has address 136.243.151.196
vsemoe.com has IPv6 address 2a01:4f8:171:1a43:5054:ff:fee4:b6d1
vsemoe.com mail is handled by 10 mail.multik.org.
bash-3.2$ host kaloshina.com
kaloshina.com has address 136.243.151.196
kaloshina.com has IPv6 address 2a01:4f8:171:1a43:5054:ff:fee4:b6d1
kaloshina.com mail is handled by 10 mail.multik.org.
bash-3.2$ host vsemoe.org
vsemoe.org has address 136.243.151.196
vsemoe.org has IPv6 address 2a01:4f8:171:1a43:5054:ff:fee4:b6d1
vsemoe.org mail is handled by 10 mail.multik.org.

В конфиг nginx добавил

location '/.well-known/acme-challenge' {
default_type "text/plain";
root /tmp/letsencrypt-auto;
}

и попробовал заказать сертификат

./letsencrypt-auto certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --agree-tos --webroot-path=/tmp/letsencrypt-auto/ -d kaloshina.com

Фигу. Создал там файлик test. Сервер в логах упорно ругается

[error] 1346#0: *3 open() "/tmp/letsencrypt-auto/.well-known/acme-challenge/test" failed (2: No such file or directory), client: 91.195.22.23, server: kaloshina.com, request: "GET /.well-known/acme-challenge/test HTTP/1.1", host: "kaloshina.com"

Хотя если проверить вручную, то этот фаил есть

cat /tmp/letsencrypt-auto/.well-known/acme-challenge/test
BLYA

Прочитал про пакость от systemd про приватные /tmp. Сменил

/lib/systemd/system/nginx.service
PrivateTmp=false

Не помогло.

Плюнул и создал каталог /opt/letsencrypt и переместил все туда

./letsencrypt-auto certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --agree-tos --webroot-path=/opt/letsencrypt/ -d vsemoe.org
Updating letsencrypt and virtual environment dependencies......
Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --agree-tos --webroot-path=/opt/letsencrypt/ -d vsemoe.org

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/vsemoe.org/fullchain.pem. Your cert will
expire on 2016-04-18. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
- If you like Let's Encrypt, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Сразу же скриптуем это 🙂

# cat /opt/ssl_get
#!/bin/bash
cd /root/letsencrypt
./letsencrypt-auto certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --agree-tos --webroot-path=/opt/letsencrypt/ -d $1

и для обновления

# cat ssl_renew
#!/bin/bash
cd /root/letsencrypt
./letsencrypt-auto --renew certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --agree-tos --webroot-path=/opt/letsencrypt/ -d $1
service nginx restart

Проверяем. У меня работает. При этом автоматом включился SNI и прекрасно раздает с одного ип-адреса много https сайтов.

Отлично, теперь пора переносить контент сайтов.

Новый сервер с игрищами и блудницами – 3

TL;DR; Статья грустная, в которой ничего почти не получилось, зато узнано много нового.

Почти вся полезная нагрузка сервера – это веб-сервера. Маленькие и не очень, требующие много места и просто пустышки. Так как я хочу сделать так, что бы все сервера были видны из интернета по SSL, то придется сделать ход конем.

Все запросы на http/https будут приходить на nginx. А тот будет работать SSL-декриптором и общаться с серверами уже по чистому http. Делать двойное шифрование-расшифрование я смысла не вижу – только трата процессорного времени. А те, кто знает про ipv6 – получат прямой доступ.

Из особенностей: машинам присваиваю имена сразу в полном формате: nginx.local.multik.org. При этом домен не пересекается с реальным, но является субдоменом. Потом, когда я буду поднимать единую систему авторизации, это сильно облегчит жизнь.

Делаем машинку для nginx

virt-install --name nginx --ram 1024 --disk path=/vm/nginx.qcow2,size=8,bus=virtio,cache=none --vcpus 2 --os-type linux --network bridge=virbr0,model=virtio --location /vm/iso/CentOS-7-x86_64-DVD-1511.iso --extra-args='console=tty0 console=ttyS0,115200n8 serial' --nographics --accelerate

и для первого сервера vsemoe.com, на котором буду тренироваться.

virt-install --name vsemoe.com --ram 1024 --disk path=/vm/vsemoe.com.qcow2,size=8,bus=virtio,cache=none --vcpus 1 --os-type linux --network bridge=virbr0,model=virtio --location /vm/iso/CentOS-7-x86_64-DVD-1511.iso --extra-args='console=tty0 console=ttyS0,115200n8 serial' --nographics --accelerate

На всякий случай проверяем, что машинки в автозапуске

virsh autostart nginx
virsh autostart vsemoe.com

На nginx – обновляемся, ставим epel-release, nginx, проколупываем дырки и ребутимся

yum update
yum install epel-release
yum install nginx
systemctl enable nginx
firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https

на vsemoe – обновляемся, ставим апач и далее по тексту

yum update
yum install httpd
systemctl enable httpd
firewall-cmd --permanent --zone=public --add-service=http

Nginx получил адреса 10.100.0.186 и 2a01:4f8:171:1a43:5054:ff:fee4:b6d1
vsemoe.com 10.100.0.178 и 2a01:4f8:171:1a43:5054:ff:fe51:f70e

Теперь иду на DNS и делаю так, что бы все видели vsemoe.com по правильным адресам

$ host vsemoe.com
vsemoe.com has address 136.243.151.196
vsemoe.com has IPv6 address 2a01:4f8:171:1a43:5054:ff:fe51:f70e

Добавляем на хосте

firewall-cmd --zone=public --add-forward-port=port=80:proto=tcp:toaddr=10.100.0.186 --permanent

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --reload

И ничего не работает. Вернее, все попытки возвращаются как connection refused. Однако если на хосте поднять nc -l 80, то все получается. Вывод – не работает порт-форвардинг.

Проверяю

[root@tower ~]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
[root@tower ~]# cat /proc/sys/net/ipv4/ip_forward
1

Все на месте. Проверяю “ручной режим”

systemctl stop firewalld
iptables -t nat -A PREROUTING -d 136.243.151.196 -i eth0 -p tcp -m multiport --dports 80 -j DNAT --to-destination 10.100.0.186

Работает. Значит где-то проблема в правилах. Читаем вывод iptables -S и натыкаемся на баг 1079088

iptables -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable

и все заработало. По крайней мере я увидел в браузере заставку от nginx.

firewall-cmd --permanent --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-forward-port=port=443:proto=tcp:toaddr=10.100.0.186 --permanent

что бы не мучаться, я создал маленький скрипт

[root@tower ~]# cat > /usr/bin/firewall-restart
#!/bin/bash
firewall-cmd --reload && sleep 1 && iptables -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
[root@tower ~]# chmod +x /usr/bin/firewall-restart

Пробуем телнетом

[root@outpost ~]# telnet vsemoe.com 80
Trying 2a01:4f8:171:1a43::2...
telnet: connect to address 2a01:4f8:171:1a43::2: Connection refused
Trying 136.243.151.196...
Connected to vsemoe.com.
Escape character is '^]'.

Так как ipv6 порты не форвардятся, то меняем адрес vsemoe.com на нормальный и пробуем

[root@outpost ~]# telnet vsemoe.com 80
Trying 2a01:4f8:171:1a43:5054:ff:fe51:f70e...
Connected to vsemoe.com.
Escape character is '^]'.
^]

Все, как и полагается. ipv4 идет на nginx, а ipv6 – напрямую на сервер.

Теперь правим nginx. Мне надо, что бы в логах указывалось, к какому серверу изначально был запрос. Добавляю “$server_name” в log-format

Добавляю описание сайта

# cat /etc/nginx/conf.d/vsemoe.com.conf
server {
listen 80;
server_name vsemoe.com www.vsemoe.com;

location ~ /.svn/ {
deny all;
}

location / {
proxy_pass http://10.100.0.178;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_buffer_size 4K;
proxy_buffers 64 4K;
}
}

Перезагружаю и вижу в браузере уже заставку apache. Значит, сработало. Сходил с ipv6 машинки – опять показало. Ура, значит еще один шаг сделан. Теперь надо зашифроваться.

Покупать сертификаты я пробовал – чертовски невыгодная штука. Но благодаря разным людям появился проект Let’s Encrypt, который позволяет получить сертификат бесплатно.

Что бы не мучаться с заставками, на vsemoe.com создал маленькую страничку

cat > index.html
this is vsemoe.com site
[root@outpost ~]# curl -4 vsemoe.com
this is vsemoe.com site
[root@outpost ~]# curl -6 vsemoe.com
this is vsemoe.com site

Опять же работает. Пора пробовать letsencypt

yum install git
git clone https://github.com/letsencrypt/letsencrypt letsencrypt

И тут я обнаруживаю, что интернет в виртуальных машинах не работает. Пинги идут, но все соединения вылетают по тайм-ауту.

Убираю правила

firewall-cmd --zone=public --remove-forward-port=port=443:proto=tcp:toaddr=10.100.0.186 --permanent
firewall-cmd --zone=public --remove-forward-port=port=80:proto=tcp:toaddr=10.100.0.186 --permanent

И все работает. Добавляю – падает. Читаю вывод iptables -S и понимаю, что там тупо все пакеты пытаются завернуться на nginx. Ни слова про интерфейс или адрес. Читаю маны и понимаю, что оно должно, но не работает. Пробую создать спец-правила

firewall-cmd --add-rich-rule='rule family="ipv4" destination address="136.243.151.196" forward-port to-addr="10.100.0.186" to-port="80" protocol="tcp" port="80"' --permanent
firewall-cmd --add-rich-rule='rule family="ipv4" destination address="136.243.151.196" forward-port to-addr="10.100.0.186" to-port="443" protocol="tcp" port="443"' --permanent

Интернет пропадает …

firewall-cmd --remove-rich-rule='rule family="ipv4" destination address="136.243.151.196" forward-port to-addr="10.100.0.186" to-port="80" protocol="tcp" port="80"' --permanent
firewall-cmd --remove-rich-rule='rule family="ipv4" destination address="136.243.151.196" forward-port to-addr="10.100.0.186" to-port="443" protocol="tcp" port="443"' --permanent

… и появляется. В конфигах (/etc/firewalld) все правильно, а в реальных правилах – ни слова про адреса. А день потерян …

Выкидываем firewalld и ставим старый добрый iptables

systemctl stop firewalld
yum -y install iptables-services
systemctl enable iptables
systemctl enable ip6tables
systemctl start iptables
systemctl start ip6tables
iptables -t nat -A PREROUTING -d 136.243.151.196 -i eth0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 10.100.0.186
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source 136.243.151.196
iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
ip6tables -D FORWARD -j REJECT --reject-with icmp6-adm-prohibited
service iptables save
service ip6tables save
yum remove firewalld

И отправляю машину в ребут, что бы проверить. Вижу кучу лишних правил, которые насовал kvm, что бы выпустить машины в интернет.

virsh net-destroy default
virsh net-edit default
virsh net-start default

Но правила все равно продолжают добавляться. Нашел еще один баг 433484. Там предлагают на хуки повешать все.

Лень. Проще в /etc/rc.d/rc.local добавить строчки


echo "Waiting for libvirt start"
sleep 5
service iptables restart
service ip6tables restart

Теперь вроде работает. Все и везде.

git clone https://github.com/letsencrypt/letsencrypt letsencrypt
cd letsencrypt/
./letsencrypt-auto

Поставит дикую кучу всего, после чего завершится со словами

Creating virtual environment...
Updating letsencrypt and virtual environment dependencies......
Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt
No installers are available on your OS yet; try running "letsencrypt-auto certonly" to get a cert you can install manually

Ну хорошо, торможу nginx

service nginx stop

И пускаю скриптик

./letsencrypt-auto certonly

Он у меня спрашивает разные вещи (типа емайла или домена) и завершается с

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/vsemoe.com/fullchain.pem. Your cert will
expire on 2016-04-16. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
- If you like Let's Encrypt, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Быстренько копирую конфиг для сервера

cat vsemoe.com.conf
server {
listen 80;
listen [::]:80;
server_name vsemoe.com www.vsemoe.com;

location ~ /.svn/ {
deny all;
}

location ~ /.ht {
deny all;
}

location '/.well-known/acme-challenge' {
default_type "text/plain";
root /tmp/letsencrypt-auto;
}

location / {
return 301 https://$server_name$request_uri;
}
}

server {
listen 443 ssl spdy;
listen [::]:443 ssl spdy;

ssl_certificate /etc/letsencrypt/live/vsemoe.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vsemoe.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/vsemoe.com/fullchain.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;

# openssl dhparam -out /etc/nginx/dhparam.pem 2048
ssl_dhparam /etc/nginx/dhparam.pem;

# What Mozilla calls "Intermediate configuration"
# Copied from https://mozilla.github.io/server-side-tls/ssl-config-generator/
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

resolver 8.8.8.8 8.8.4.4 valid=86400;
resolver_timeout 10;

location / {
proxy_pass http://10.100.0.178;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_buffer_size 4K;
proxy_buffers 64 4K;
}
}

Генерирую требуемое (долго идет)

openssl dhparam -out /etc/nginx/dhparam.pem 2048

Перезапускаю nginx, захожу браузером … и ляпота!

Screenshot 2016-01-17 20.37.26

Ну и проверка …

Screenshot 2016-01-17 20.47.00

Следующим шагом разрулим ситуацию с ipv6.

Новый сервер с игрищами и блудницами – 2

Итак, надо виртуализироваться. Виртуализироваться будем через KVM потому что опять же продвигается редхатом, всеми поддерживается и так далее и тому подобное.

Для начала ставим кучку жутко “необходимого” софта: yum install qemu-kvm libvirt python-virtinst bridge-utils

Затем запускаем установленное

systemctl start libvirtd
systemctl enable libvirtd

Опять же, ничего такого вроде не появилось, за исключением пары интерфейсов с названиями virbr и адресом 192.168.122.1/24.

3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 52:54:00:ba:d8:82 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 500
link/ether 52:54:00:ba:d8:82 brd ff:ff:ff:ff:ff:ff

Первым делом мне надо добавить ipv6 адрес. Только не вздумайте искать по совпадениям и править руками. Есть гораздо более приятные средства.

virsh net-destroy default
virsh net-edit default

Screenshot 2016-01-16 15.18.40

И добавим еще одно определение сети.

Screenshot 2016-01-16 15.27.38

virsh net-start default

Screenshot 2016-01-16 15.30.24

а в логах должно быть что-то похожее на

Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: DHCP, IP range 10.100.0.100 -- 10.100.0.200, lease time 1h
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: DHCPv6, IP range 2a01:4f8:171:1a43:8000::1000 -- 2a01:4f8:171:1a43:8000::2000, lease time 1h
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: router advertisement on 2a01:4f8:171:1a43::
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: IPv6 router advertisement enabled

Откуда появился 2a01:4f8:171:1a43:8000::2/96 ?

Дело в том, что hetzner выдал мне ipv6 адрес 2a01:4f8:171:1a43::2/64. Типа подсеть на хост и все такое. Я взял с серединки (:8000) кусочек в 32 бита (128-96) или 4 миллиарда адресов. Ну или столько, сколько сейчас адресов в интернете 🙂 Из этого диапазона я выделил малюсенький кусочек в тысячу адресов для виртуалок. Думаю, что мне этого хватит 🙂 Ну и заодно поменял адрес для ipv4 на более подходящий мне.

Теперь самое время проверить доступность с другого хоста.

[root@outpost ~]# ping6 2a01:4f8:171:1a43:8000::2 -c 2
PING 2a01:4f8:171:1a43:8000::2(2a01:4f8:171:1a43:8000::2) 56 data bytes
64 bytes from 2a01:4f8:171:1a43:8000::2: icmp_seq=1 ttl=59 time=0.864 ms
64 bytes from 2a01:4f8:171:1a43:8000::2: icmp_seq=2 ttl=59 time=0.490 ms

--- 2a01:4f8:171:1a43:8000::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.490/0.677/0.864/0.187 ms
[root@outpost ~]# ping6 2a01:4f8:171:1a43::2 -c 2
PING 2a01:4f8:171:1a43::2(2a01:4f8:171:1a43::2) 56 data bytes
64 bytes from 2a01:4f8:171:1a43::2: icmp_seq=1 ttl=59 time=0.341 ms
64 bytes from 2a01:4f8:171:1a43::2: icmp_seq=2 ttl=59 time=0.452 ms

--- 2a01:4f8:171:1a43::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.341/0.396/0.452/0.058 ms

В общем, все как в ipv4, только маски дикие по размерам и не привычные.

Теперь надо поднять какую-нибудь виртуалку, что бы протестировать роутинг и прочие штуки.

Добавляем полезную утилиту для лентяев yum install virt-install virt-viewer

И останавливаемся. Потому что нам надо выделить немножко места для виртуалок.

lvcreate -L 100G -n vm vg0
mkfs.xfs /dev/vg0/vm
mkdir /vm
mcedit /etc/fstab
mount /vm

100Гб для начала хватит, а потом по необходимости растяну.

Так как я хардкорничаю, то добавляю необходимое для selinux

yum install policycoreutils-python
semanage fcontext -a -t virt_image_t "/vm(/.*)?"
restorecon -R /vm

И выкачиваю дистрибутив CentOS (Тут немного бальзама: качается по ipv6. Мелочь, а приятно)

mkdir /vm/iso
cd /vm/iso
wget http://ftp.funet.fi/pub/mirrors/centos.org/7/isos/x86_64/CentOS-7-x86_64-DVD-1511.iso

Ну и теперь пора поставить тестовую машину. Пока без всяких ускорений, акселераций и прочего. Мне надо просто проверить сеть и все, что с ней связано.

virt-install --name test --ram 1024 --disk path=/vm/test.qcow2,size=8 --vcpus 1 --os-type linux --network bridge=virbr0 --location /vm/iso/CentOS-7-x86_64-DVD-1511.iso --extra-args='console=tty0 console=ttyS0,115200n8 serial' --nographics

Значение каждого параметра либо понятны сразу, либо описаны в документации или интернете. Если все сделали правильно (я каюсь, не сразу все сделал правильно, но это оставим за скобками), то вы должны увидеть текстовый интерфейс, очень похожий расположением элементов на графический. Инсталлятор понятен любому, кто хоть раз ставил центось. В общем, после указания всех шагов получим наглядную иллюстрацию процесса инсталляции.

Screenshot 2016-01-16 16.40.05

После установки мы увидим консоль сервера и может туда залогиниться и даже попинговать ipv4 адреса. ipv6 не пингуется, потому что на интерфейсе сидит только локальный адрес.

Screenshot 2016-01-16 17.37.01

Более того, можно даже немного поэстетствовать и использовать графический virt-manager. Правда, придется добавить немного пакетов, что бы графическая часть морды не ругалась.

yum install xauth libcanberra-gtk3 PackageKit-gtk3-module dejavu-lgc-sans-fonts dejavu-lgc-sans-mono-fonts

Если virt-manager ругается на то, что консоль занята, значит вы не отцепились (Ctrl-]) от текстовой в другом терминале

Ну и затем с любого линукса ssh -X на машину и я получаю вот это.

Screenshot 2016-01-16 17.50.45

В принципе, полный контроль над машинами. Иногда очень удобно, иногда нет.

Но я отвлекся. В виртуальной машине ipv4 есть, получен и даже работает, а ipv6 нет. И еще тормозит по диску уж больно жутко.

Диск лечится просто: тормозим машину, virsh edit test и где driver добавляем cache=’unsafe’ (для рабочих не надо так делать). После запускаем и видим вполне себе шустро бегающую машинку.

Теперь с сетью. Заходим на тестовую машину, запускаем dhclient -6 ens3 (ens3 это у меня сетевой интерфейс). И видим в логах

Jan 16 16:30:58 tower dnsmasq-dhcp[3544]: no address range available for DHCPv6 request via virbr0

Оппа! А почему? Вроде же определили все и выдали тоже все …

Прибиваем в тестовой машине адрес 2a01:4f8:171:1a43:8000::99 и пингуем – пингуется, но только с хоста. Это нормально.

Как прибить? В /etc/sysconfig/network-scripts/ifcfg-ens3

#IPV6_AUTOCONF=yes
IPV6ADDR=2a01:4f8:171:1a43:8000::1234

и перезапустить network

Так, раз пингуется, значит проблема не в адресе, а в настройках. Судя по аналогичным сообщениям, у меня проблемы с маской. Почитав еще немного интернетов, я дошел до такой конфигурации.

<ip family='ipv6' address='2a01:4f8:171:1a43:8000::2' prefix='64'>
<dhcp>
<range start='2a01:4f8:171:1a43:8000::100' end='2a01:4f8:171:1a43:8000::200'/>
</dhcp>
</ip>

Как видите, разница только в маске. Как ни странно, но в этом отношении ipv6 (вернее, его роутинг в линуксе) ведет себя немного “странней”, чем для ipv4. Но в любом случае, прочитанное оказалось верным и машина получила свой адрес.

Jan 16 18:03:01 tower dnsmasq-dhcp[5491]: DHCPREQUEST(virbr0) 10.100.0.141 52:54:00:81:5b:8f
Jan 16 18:03:01 tower dnsmasq-dhcp[5491]: DHCPACK(virbr0) 10.100.0.141 52:54:00:81:5b:8f test
Jan 16 18:03:03 tower dnsmasq-dhcp[5491]: RTR-SOLICIT(virbr0)
Jan 16 18:03:03 tower dnsmasq-dhcp[5491]: RTR-ADVERT(virbr0) 2a01:4f8:171:1a43::
Jan 16 18:03:03 tower dnsmasq-dhcp[5491]: DHCPCONFIRM(virbr0) 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:04 tower dnsmasq-dhcp[5491]: DHCPSOLICIT(virbr0) 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:04 tower dnsmasq-dhcp[5491]: DHCPADVERTISE(virbr0) 2a01:4f8:171:1a43:8000::13c 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:05 tower dnsmasq-dhcp[5491]: DHCPREQUEST(virbr0) 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:05 tower dnsmasq-dhcp[5491]: DHCPREPLY(virbr0) 2a01:4f8:171:1a43:8000::13c 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f

Вывод ip addr

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:81:5b:8f brd ff:ff:ff:ff:ff:ff
inet 10.100.0.141/24 brd 10.100.0.255 scope global dynamic ens3
valid_lft 3590sec preferred_lft 3590sec
inet6 2a01:4f8:171:1a43:8000::13c/128 scope global dynamic
valid_lft 3595sec preferred_lft 3595sec
inet6 fe80::5054:ff:fe81:5b8f/64 scope link
valid_lft forever preferred_lft forever

Как видно, сервер получил свой персональный ipv6 адрес, но ничего, кроме хоста пинговать не может. Причина простая как грабли – ipv6 не имеет NAT в принципе. Только роутинг.

Косвенным подтверждением является попытка попинговать адрес тестовой машины снаружи

[root@outpost ~]# ping6 2a01:4f8:171:1a43:8000::13c
PING 2a01:4f8:171:1a43:8000::13c(2a01:4f8:171:1a43:8000::13c) 56 data bytes
From 2a01:4f8:171:1a43::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:4f8:171:1a43::2 icmp_seq=2 Destination unreachable: Address unreachable

То есть пинг доходит до хоста, а тот отвечает, что не знает, куда роутить этот адрес. Аналогичное получим, если попытаемся напрямую с хоста попинговать. Ну нету этого адреса в таблице роутинга и все тут. Меняем маску на основном интерфейсе (64->128), что бы таблицу роутинга в порядок привести. Без перезагрузки

ip addr del 2a01:4f8:171:1a43::2/64 dev eth0
ip addr add 2a01:4f8:171:1a43::2/128 dev eth0

А с перезагрузкой в /etc/sysconfig/network-scripts/ifcfg-eth0

Что изменилось? С хоста началась пинговаться виртуалка и все. В общем, лично мне стало понятно, что ipv6 – это нифига не ipv4, только с бОльшими масками.

(чтение мануалов опущено)

В общем, с одной стороны все проще, а с другой – все сложнее. В ipv6 есть такая штука, как SLAAC, которая работает как некий навороченный DHCP сервер. Подробнее в маны.

Поэтому выкидываю нафиг все из настроек dnsmasq (virsh net-edit default) и оставляю только описание интерфейса.

<ip family='ipv6' address='2a01:4f8:171:1a43::3' prefix='64'>
</ip>

Ну и адрес попроще сделал. И сделал /etc/radvd.conf

interface virbr0
{
AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;
prefix 2a01:4f8:171:1a43::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
RDNSS 2001:db8:0:a0a1::add:1010
2001:db8:0:a102::add:9999
2001:db8:0:a111::add:9898
{
};
};

Затем

systemctl enable radvd.service
systemctl start radvd.service

и перезагрузка виртуалки. Вуаля! Магия ipv6 сработала и виртуалка получила свой адрес.

inet6 2a01:4f8:171:1a43:5054:ff:fe81:5b8f/64 scope global noprefixroute dynamic
valid_lft 86170sec preferred_lft 14170sec

И даже пинги ходят во все стороны. То, что и требовалось получить.

Для проверки я создал еще одну виртуалочку (теперь с сразу с “быстрым” диском)

virt-install --name test2 --ram 1024 --disk path=/vm/test2.qcow2,size=8,bus=virtio,cache=none --vcpus 1 --os-type linux --network bridge=virbr0 --location /vm/iso/CentOS-7-x86_64-DVD-1511.iso --extra-args='console=tty0 console=ttyS0,115200n8 serial' --nographics

И сеть в ней сразу заработала без каких-либо дополнительных команд. То, что и требовалось получить. Теперь можно и виртуалки клепать.

Как выдаются адреса? А очень просто: простым маппингом мак-адреса сетевой. Опять же за подробностями в документацию.

link/ether 52:54:00:e4:63:05 brd ff:ff:ff:ff:ff:ff
inet6 2a01:4f8:171:1a43:5054:ff:fee4:6305/64 scope global noprefixroute dynamic

Главное изменение теперь в “политике безопасности”.

Раньше: вся сетевая безопасность лежала на хосте. Гости получали уже отфильтрованный трафик, только на те порты, которые разрешены. Можно было спокойно открывать порты, не опасаясь ничего.

Теперь: каждый гость выставлен наружу “напрямую” и требует соответствующей защиты. И не важно, что ipv4 адреса из “приватной” сети. Фаирволл, обновление и выключение ненужного – наше все.

Не страшно и не сложно, но помнить надо.

Итак, считаю, что очередной шаг закрыт. Теперь надо переносить существующее (разумеется, с одновременным апгрейдом)

Новый сервер с игрищами и блудницами – 1

Пришла ко мне рассылка от hetzner. Дескать, дорогой валуабный клиент, сделали мы новую линейку серверов. Памяти больше, проц быстрее, диски толще а денег надо меньше. Приходи и заказывай. Походил я кругами и заказал. А то на старом уже диски сыпаться начали и своп образовываться.

Но просто так переносить сервисы абсолютно не интересно: на старом сервере у меня стоит OpenVZ и весь перенос будет заключаться в паре команд, да смене имен в DNS. Где же развитие и толчок вперед? В общем, потыкался я и решил:

– Сменить основную OS с CentOS 6 на CentOS 7. systemd, firewalld и прочие d в полном изобилии. Некий опыт есть, но чего-то в голову лезут пошлые мысли про RHCE.
– Привести в порядок DNS. Сейчас у меня часть серверов тут, часть там, часть вообще через одно место. Пусть все будет одинаковым и у меня.
– ipv6. Не очень-то и надо, но смотреть выше про развитие.
– SNI. Хватит тратить ipv4 адреса на каждый SSL сервер (да и дешевле будет).
– Да и вообще, надо все закриптовать. А то стыдоба – личный SVN голым ходит.
– Ну и KVM надо. Иногда жутко как требуется винда “в прекрасном и далеком”, а городить туннели не охота. Заодно получится бесплатный терминальный сервер для меня любимого.
– OwnCloud тоже не помешал бы, как и OpenVPN сервер для разностей нехороших.
– Ну и остальное по вкусу.

Практика прошлых лет показала, что принцип “ставим один сервер, выкидываем с него лишнее, а все сервисы в виртуалки” оправдал себя на все 100%. Да, при настройке чуть-чуть подумать надо, но зато потом абсолютно никаких проблем и заморочек. Ни с хакерами, ни с распределением нагрузки, ни с резервным копированием … да вообще ни с чем. Так буду и тут делать.

Идем в админку и заказываем новый сервер. Ждем получения письма, в котором пишут радостное:

Screenshot 2016-01-16 10.52.41

Заходим, нас пускают …

Screenshot 2016-01-16 10.52.57

Для приличия делаем passwd root и начинаем осматриваться. Сразу замечаю, что немцы стойко держат флаг “мы делаем нах ордунг” и сделали два больших рейда по 2Тб. Один отдали под /, другой под /home. Интересно, какой у них был сценарий использования? Но в любом случае, мне такое не надо.

Идем опять в консоль и перегружаемся в rescue

Screenshot 2016-01-16 11.04.38

Выглядит именно тем, что я и заказывал (каюсь, да, не посмотрел раньше). Поэтому сразу набираем installimage

Там нам дают в mcedit поправить конфиг. Там я меняю имя сервера на tower.multik.org и ниже я показал, как указываю 16 гигов свопа, 512 мегабайт для /boot и все остальное отдать в LVM. В LVM прошу создать раздел / размером в 16 гигов. Остальное оставить нетронутым. Почему так мало? Так потому что все остальное – в виртуалки! В корне сервера делать лишнему абсолютно нечего, тут будут только штуки, связанные с внешним миром типа фаирволла.

Screenshot 2016-01-16 11.42.58

Сохраняю (F2 или ESC-2), выхожу (ESC-0 или F10) и жду перезаливки сервера

Screenshot 2016-01-16 11.10.30

Потом reboot, снова захожу (про ключи и их смену не говорю) и вуаля! Я в новом сервере.

Screenshot 2016-01-16 11.23.09

Опять меняю пароль root.

Итак, на этом этапе я получил пустой и голый сервер. Что он умеет? Да ничего. Добрые немцы выкусили из образа вообще все (вот тут реально молодцы!) и на сервере есть только ssh и настроенная ipv4/ipv6 сеть.

Первым (опять первым, но тут все такое) делом обновляемся. yum update

Добавляем полезные программки yum install mc screen bind-utils iotop iftop

Включаем синхронизацию времени systemctl start ntpd && systemctl enable ntpd

и переходим к фаирволлу. yum install firewalld ; systemctl enable firewalld ; systemctl start firewalld (Почему firewalld? Потому что мне лень править правила для ipv4 и ipv6 одновременно. Ну и редхатом проталкивается)

Внешне ничего не изменилось, но теперь снаружи на машину можно зайти только по 22му порту. Проверить можно посмотрев правила iptables. Но я-то двигаюсь вперед, поэтому все должно быть по фен-шую.

systemctl status firewalld

Screenshot 2016-01-16 12.13.29

и побалуемся с командой firewall-cmd

Screenshot 2016-01-16 12.15.57

Если я правильно понял, то никаких активных правил нет, просто стоит public по умолчанию, в которой разрешен только dhcp-клиент и ssh. Все остальное запрещено. Вполне логичные правила, но опять же, мне не сильно подходят. Будем менять.

Для начала попробую

firewall-cmd --zone=public --change-interface=eth0 --permanent
firewall-cmd --get-active-zones

И вижу фигу. Ничего не изменилось. Оказывается, это фича. Скрипт видит, что зона public и так применена (ну и что, что по умолчанию, поэтому ничего не делает).

Меняю зону на home и обратно. Вот теперь показывает

Screenshot 2016-01-16 12.27.56

Но лично мне не нужно, что бы было правило для dhcp клиента

firewall-cmd --zone=public --remove-service=dhcpv6-client --permanent
firewall-cmd --list-all

Ну вот теперь хорошо. Ничего лишнего, все закрыто и замуровано. Остался последний шаг – применить все, что я тут натворил, в реальность

firewall-cmd --reload

Все, теперь и iptables показывает именно то, что полагается.

Как говорится, первый шаг сделан. Следующим – виртуализироваться. Но виртуализироваться хардкорно, поэтому ставим SELINUX=permissive для начала и перезагружаемся, проверяя правильность всего преднастроенного.

У меня выползла одна единственная проблема – предустановленный немцами chrony мешался ntpd. Удаляем его (yum remove chrony) и все.

PS В запоминалку: настроить монитор raid.

Места всегда мало! Или ищем место онлайн.

Мы сейчас находимся в период очень интересных ценовых войн за пользователя. Все сервисы пошли в интернет, вместо покупки предлагается подписка и прочее, прочее, прочее. И то, что сначала казалось прорывом, сейчас не вызывает никаких эмоций.

Вот и мне потребовалось найти немного места в онлайне. С одной стороны, искать мне место в онлайне … Ну странно как-то. Есть и свой сервер в германии, где как минимум терабайт простаивает и где можно развернуть тот же owncloud, а с другой стороны, на нем и так уже крутится куча всего полезного, которое неплохо было бы положить еще куда-нибудь.

Итак, что мне надо?

Мне надо некий сервис, в который я положу следующее

Примерно 200Гб всяких штучек, которые мне потерять нет желания.
Примерно 300Гб других штучек, которые мне дороги как память
Ну и примерно 20Гб фотографий.

Ну и как обычно, аппетиты приходят во время еды, поэтому сразу замахнусь на терабайт места.

Что мне надо?

Мне нужна поддержка всех трех платформ – linux, os x, windows. Пусть через нное место, но что бы все работало. Никаких браузеров, “у нас в разработке” и так далее.

Мне нужны “прокачанные” технологии. Сидеть как dropbox на плечах amazon’а конечно хорошо, но охота более прямого контакта. Зачем? Да просто так.

И мне не нужна “халява”. Если халява – значит никаких гарантий и никакой возможности хотя бы покачать права.

Для начала пойдем по отечественным сервисам.

Яндекс.Диск. 200 рублей за 1Тб в месяц. Есть прямой доступ до диска через dav_fs, что для меня является большим плюсом. Минус – как любая компания, живущая от рекламы, Яндекс собирает о пользователе все, до чего сможет дотянуться.

Облако mail.ru. Цен на сайте не нашел, другие сайты говорят про 499 рублей в месяц. Но я имею крайне печальный опыт работы с mail.ru, поэтому данная компания даже не рассматривается и здесь приведена из-за того, что она есть.

В общем-то на этом отечественные провайдеры кончаются, не успев начаться. Пойдем по импортным

Dropbox. Самый первый, самый широко поддерживаемый сервис. За 1Тб желают 10 долларов в месяц или 700 рублей.

iCloud. За терабайт хотят 19 долларов в месяц. Или 1400 рублей в месяц.

Microsoft OneDrive. 199 рублей в месяц. И добавляют еще лицензию на Office 365 (Word, Excel и прочие штуки).

Кажется, тут выбор очевиден. Тем более, я недавно попробовал Windows 10 … и знаете, она мне понравилась.

Update: капиталисты не смогли не подгадить и в итоге не 200 рублей в месяц, а целых 286. Я близок к разорению 🙂

Кластер против облака …

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

На всякий случай у меня под боком есть два компьютера. Ну как компьютеры … по нынешним меркам они скорее обзываются калькуляторами. Но тем не менее все необходимое у них есть. Пару-тройку виртуалок они потянут, а больше для меня и не надо.

Упражнение первое или “мама, у нас все сломалось”. Везде пишут (ну и я тоже), что системы виртуализации позволяют осуществлять онлайн-миграцию. А как это поисходит вживую?

cloud1

Вот вам пример. В одном окошке я запустил миграцию виртуальной машины с одной ноды “калькуляторного кластера” на другую, а во втором – просто посылал в сторону мигрируемой машины по пакету в секунду. Как видно на скриншоте, время недоступности машины составило 9 секунд. Общее время миграции было около 30 секунд. На настоящих кластерах время недоступности обычно не превышает и половины секунды. Много ли сервисов требуют для себя такого уровня доступности?

Или вот еще один пример, опять же многократно описываемый. Есть сервис, которому не хватает ресурсов.

cloud2

Если посмотрите на правое окошко (там консоль одной из виртуалок), то там openssl показывает, что он может подсчитать только 11 тысяч хешей md2 за 0.15с. А потом команда free докладывает, что памяти всего 256 мегабайт. Одна команда в левом окошке (на ноде) и openssl уже подсчитывает 540 тысяч за 3 секунды (или 27 тыщ за то же время), а памяти стало уже гигабайт. И все это без остановки или перезагрузки сервиса.

И так можно крутить любой параметр у виртуалки: начиная от числа и скорости процессоров и заканчивая количеством дискового пространства у машины.

Для интереса предлагаю прикинуть, сколько потребуется времени и сил, что бы проделать подобное в обычной инфраструктуре. Удобно? Не то слово!

Надо развернуть новый сервер? Легко!

cloud3

17 секунд (калькулятор, да) и у вас есть готовая машина, которой надо только выделить ресурсы.

cloud4

А когда нужда в ней отпадет … секунда и ненужной машины больше нет.

Точно таким же образом машины можно клонировать или тиражировать, снапшотить для бекапа и выполнять кучу других полезных действий.

Повторюсь, все это сейчас позволяет делать любая система виртуализации.

Но все-таки, чем отличаются облака от кластеров? Ведь они построены на одних и тех же принципах, позволяют делать одно и то же с одним и тем же результатом.

Отличаются они одним. Системой управления всем этим великолепием.

Во-первых, считается что облака дают возможность обычному (в смысле не имеющему доступа до нод) пользователю самому управлять своими машинами. Критерий спорный, но вполне имеет право на жизнь, ибо я еще ни разу к примеру не встречал на кластерах биллинг. А вот для облаков это неприменный атрибут.

Во-вторых, системы управления заточены на разделение ресурсов. В кластере редко возникает необходимость отделить одну группу серверов от другой. В результате все сидят в нескольких VLAN’ах, разрулить которые легко руками. А в облаках тысячи (десятки, сотни – подставьте по вкусу) пользователей, которых надо развести по своим сетям и не давать серверам одного пользователя прямого доступа к серверам другого. Без системы управления, заточенной на облака, подобная затея попросту обречена на провал.

И наконец, облака тащат в себе всю … скажем так, специфику виртуализации. Скажем, для одного сервиса необходимы ноды, которые используют локальное хранилище, да и еще на SSD. А для другого хватит кусочка общего стораджа. Для каждого сервиса есть свои ограничения, требования, правила. И системы управления следят за тем (скажем, при миграциях), что бы каждый сервис работал на ресурсах того класса, который ему выделен, что бы не происходило overselling (или он был с заранее определенными параметрами) и так далее и тому подобное.

Поверьте, все это удержать в голове и рулить этим через консоль или какую-нибудь утилитку – абсолютно нереальная задача.

И вот за вот это вот снятие “головной боли админа” и просят производители денег. А так-то все можно сделать руками и из консоли …

Как самому сделать себе немного облака. Часть вторая.

IMG_8985

Итак, переходим к самому волнующему: под какой системой виртуализации будет работать наше облако? Простой поиск по интернету выдает такие разнообразные варианты, что прямо теряешься.

На самом деле ответ на этот простой: ставьте ту систему, специалисты по которой наиболее доступны вам. Что бы было у кого и с кого спрашивать.

Но это же не интересно и писать не о чем. Поэтому давайте я опишу личные впечатления о разных системах, которые можно заиспользовать.

Начну с моей любимой: OpenVZ (Коммерческая Virtuozzo). Самая скоростная система, которая по производительности легко уделывает все остальные. Имеет только один, зато толстый минус: позволяет внутри крутить только linux системы.

VMware. Самая старая, дорогая и поддерживаемая система. Есть бесплатные вариант ESXi, но возможностей у него кот наплакал. За деньги можно сделать систему абсолютно любого уровня. Основные минусы: цена и дикая нелюбовь к несертифицированному железу.

Xen. В коммерческом варианте – Citrix. В России я не видел нормальных внедрений, поэтому опыта у меня нет. Зато за рубежом одни из крупнейших провайдеров – Amazon и RackSpace использует именно его.

KVM. На самом деле это простой гипервизор, который есть в любом дистрибутиве линукса. Управляется исключительно из командной строки. Но благодаря поддержке гигантов, оброс различными системами управления и надстройками, которые позволяют конкурировать с системами на базе VMware. RedHat использует именно его.

Hyper-V. Продукт от микрософта и заточенный на работу с микрософтовскими же продуктами. Не так давно научился и linux крутить. Дорогой и пока глючный (ну или мне так везет).

VirtualBox. Бесплатная (для десктопа) виртуализация. Но если вам приходится много работать с Solaris или Oracle, то это единственный выбор.

В общем-то и все. Остальные системы пока в слишком зачаточном состоянии.

По функционалу все системы одинаковы. То есть заморачиваться вопросами «а умеет ли эта система что-то, что не умеет другая» абсолютно нет смысла: все необходимое есть. Разница в том, насколько удобно реализованы те или иные возможности.

К примеру, vmware имеет в комплекте конвертор, который позволяет с минимальными усилиями затащить в себя любую физическую машину, работающую под windows или linux. Она же единственная, кто дружит с OS X. Зато OpenVZ позволяет сделать так, чтобы файловая система (и сама виртуалка) была доступна с хост-машины без каких-либо проблем (и при необходимости наоборот). А KVM доступна на любой линукс-машине и позволяет с минимальными телодвижениями запустить образ от других систем. Ну и если у вас целиком вся инфраструктура на продуктах от микрософта, то с помощью Hyper-V вы мигрируете в облака без особых телодвижений.

В общем, крайне рекомендую перед окончательным выбором протестировать все системы под свои требования. Благо у всех систем есть триальные версии.

Хинт: нет никакой необходимости делать все на одной системе. Никто не мешает использовать несколько. Да, получится более сложная инфраструктура, но возможно более эффективная.
Ндас, как-то не очень маркетоидно получилось, зато про всех понемногу. Давайте лучше вернемся к приятному: планированию облака.

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

За что борются инженеры?

Во-первых, за скорость. Диск и сеть должны выдавать максимальные значения, дабы уменьшить простой процессоров на нодах.

Во-вторых, за число операций в секунду. Для дисков это зовется IOPS, для сети pps. Чем больше операций система может провернуть, тем меньше надо систем для обработки того же объема запросов.
Для этих значений принцип простой: чем больше, тем лучше. И поверьте, борьба за эти циферки идет жесточайшая. Их всегда не хватает. Вообще всегда.

Какие основные методы применяют?

Во-первых, разделение машин по функционалу. Скажем, у вас есть 10 веб-серверов. Предположим, что внутри каждого веб-сервера есть сам веб-сервер с каким-то движком (типа php или java) и SQL сервер. Простой вынос всех этих десяти маленьких SQL серверов на один (хорошо, на два, если нужна отказоустойчивость), но которому отдали их ресурсы, уже приведет к увеличению производительности.

Во-вторых, разделение потоков данных. Это тема в большинстве случаев сродни шаманству. Людей, которые понимают, где в обычных с виду систем могут возникать бутылочные горлышки и как их удалять, очень ценят.
Скажем же веб-сервер. Скажем, ему банально стало не хватать производительности. Поднять второй по каким-то причинам нельзя. Что делают в «лоб»? Обычно наращивают производительность. Скажем ставят SSD вместо обычных дисков. Да, производительность возрастет, но не сильно. Специалист «по горлышкам» придет и увидит, что у веб-сервера есть один поток на чтение, когда он отдает запрошенное, один поток на запись, когда он записывает в лог и еще один поток на запись, когда операционная система обновляет время последнего доступа к файлу. В результате достаточно отрубить время доступа (нафиг он на веб-сервере?) и поднять где-нибудь неподалеку сервер для сбора логов, как дисковой подсистеме отвечающей за веб-сервера резко полегчает: она будет работать только на чтение (и никто не мешает ей поставить RO, что бы еще больше облегчить жизнь). А у сервера логов только на запись. Все счастливы и довольны.

Есть и еще одно «шаманство». Обзывается разделением нагрузки по характеру. Скажем, у нас есть бухгалтерия и почта. Бухгалтерский сервер использует паттерн работы с диском «тут посмотрели, тут записали, тут посмотрели, тут записали» (упрощенно конечно). А почта «записали, посмотрели, посмотрели, посмотрели, записали». Причем временные интервалы и расстояния по диску между «посмотрели» и «записали» у обоих систем разные. В результате кэш, который обязан ускорять работу с диском, банально «загрязняется» и работает далеко не так эффективно, как мог бы.

Да, примеры немного наиграны, но и реальность просто отличается большим числом участвующих «переменных».

Ладно, хватит пугать, надо немного рассказать о типичных методах ускорения сети и дисков и встреченных мной (и совершенных тоже) ошибках.

Объединение линков. Как я писал выше, скорости никогда не хватает. Все сетевые штуки умеют объединять несколько сетевых линков в один. Скажем, у вас в сервере есть 4 порта, каждый на 1Гбит. И в коммутаторе тоже образовалось свободное место. Вы берете 4 патч-корда и соединяете их один-к-одному, включаете бондинг (объединяете их в один транк и так далее) и надеетесь, что в результате получите линк на 4Гбит. А в результате получаете тот же гигабит или чуть больше. Любой продвинутый сетевик уже понял, в чем засада. Для остальных: у бондинга много режимов и вариантов. И только некоторые предусматривают возможность распределение нагрузки по всем линкам.

Звезда – наше все. Это любимая и продвигаемая большинством модель построения сети. Если коротко, то все сетевые устройства подключаются к некой системе, которая уже и занимается передачей пакетов от одного устройства к другому. Просто, понятно и … дорого. Штуки, которые способны переваривать десятки и сотни гигабит (Откуда такие цифры? К примеру, одна виртуалка с бухгалтерией легко генерирует поток в гигабит к диску. Это всего-то 100 мегабайт в секунду. Обычный винт легко выдает) и при этом не становиться единой точкой отказа, стоят дорого. Для обычной сети эта модель практически идеальна. Но у облаков все немного по-другому. Скажем, есть очень большой поток данных между серверами хранения. Не к нодам, а тупо между собой. Для репликации, отказоустойчивости и все прочее. Более того, весь поток сосредоточен между серверами одной группы. Так зачем его гонять через коммутатор, когда гораздо выгодней зацепить сервера между собой прямыми линками? Просто из-за такого изменения топологии задержка в линке падает больше чем в 2 раза! И ведь точно такой же поток данных есть и между нодами …

Не все рэйды одинаково полезны. Скажем, нам нужно создать отказоустойчивый сервер хранения. Надо немного, буквально 20 терабайт. Что делает обычный, не «облачный» админ? Берет два сервера, пихает в каждый по шесть дисков на 4 терабайта, запихивает их в raid5 на отдельном контроллере, объединяет сервера и рапортует о готовности. В результате получается тормозной сторадж, который с трудом способен переварить 400-500 мегабайт данных в секунду. Что делает облачный админ? Берет десять дисков по паре терабайт, делает raid0 средствами операционной системы и затем объединяет сервера. Получившаяся шарманка легко берет планку гигабайт в секунду и не дохнет от на порядок больших IOPSов. Да и еще дешевле оказывается. Почему так получилось? Во-первых, облачный админ исключил лишний уровень отказоустойчивости. Зачем его дублировать на уровне дисков, когда он уже есть на уровне серверов? Во-вторых, raid0 сам по себе работает гораздо быстрее raid5, а тут вдобавок данные обрабатывают 10 дисков против 5 (и не надо ждать, пока raid5 завершит запись на всех дисках). И наконец, он освободил ресурсы процессора от расчета всяких контрольных сумм (если кто-то думает, что отдельные raid контроллеры работают быстрее обычного процессора, то он очень сильно заблуждается). Результат: выигрыш в скорости, выигрыш в IOPSах, выигрыш в деньгах! Сплошной профит!

SSD супротив памяти проигрывает всегда! Последнее время пошла мода ставить SSD для кеширования обычных HDD. Для десктопов это реально увеличивает скорость общения с диском. А вот с облаками эта штука практически не дает прироста. Просто из-за того, что слишком хорошо распределена нагрузка и редко когда в SSD попадает то, что можно закешировать. А ставить их пачками – дорого. Но почему-то редко кто додумывается поставить на сервер хранения не жалкие 16-32 гига памяти, а 256 или 512 и оттюнить операционку на максимальное использование кэша. Поверьте, эффект будет заметен невооружённым взглядом.

Но и это не все, над чем придется поломать голову. При переводе систем в облака крайне рекомендую заранее озаботиться в их установке в варианте, который позволяет масштабироваться с минимальными усилиями или исключить ненужное дублирование. Скажем, для систем на базе jboss можно почти расслабиться: он сам умеет находить аналогичные сервера и парралелить работу. Сервера с MySQL достаточно сразу поднимать в не в конфигурации standalone, а master: потом подцепить другой master или slave будет гораздо проще. Резервное копирование осуществлять не с помощью агентов изнутри каждой виртуалки, а централизовано, на сервере хранения.

Хинт: определить, что лишнее, довольно просто. Просто берете и мысленно ставите рядом еще одну точно такую же систему. Общие данные и там и там? Выносим на отдельную виртуалку/общий каталог на сторадже. Один и тот же сервис делает одну и ту же работу с одним набором данных? В отдельную виртуалку! Какой-то внешний сервис приходит регулярно за каким-то данными? Меняем схему, что бы не он приходил, а мы ему отправляли. И так далее и тому подобное.

В результате у вас должно получиться примерно в 3-4 раза больше «облачных» серверов, чем было «физических» сервисов. Но все сервера будут выполнять одну функцию, их будет легко собрать в группы по характеристикам и все они будут довольно легко масштабироваться.

Только заклинаю вас: сразу все определите правила для поименования, нумерации сети и документирования. Нет ничего хуже, чем обозревать сеть с server1, server2, test-server, lama, vanya (брать имена городов, животных, клички ничем не лучше). Поверьте, даже для небольшой компании со временем легко набирается сотня-другая виртуальных серверов. В имени сервера должно присутствовать как минимум указание на его функциональную сущность (например stor, node, app, web), его уникальный номер (хорошо если привязанный к его адресу в сети) и если необходимо, какой-либо другой признак (dev, ivan, test). А за отход от правил тут же и немедленно бить чем угодно. Но еще лучше помогает тупо удаление сервера: второй раз никто такую ошибку обычно не допускает.

И тогда любой при взгляде на stor25fast сможет сказать, что это сервер хранения для требовательных к ресурсам задач с адресом 10.0.0.25, a web40-test-ivan – тестовая машинка с веб-сервером, поднятая Иваном и имеющая адрес 172.16.0.40. Думаю, смысл понятен.

Думаю, я достаточно загрузил вас. Пора немного прерваться.

И да, я опять спер картинку

Как самому сделать себе немного облака. Часть первая.

cloud
Данный текст я решил написать в расчете на ИТшников, которые уже задумались про перевод своей инфраструктуры в «облака» и теперь думают, как же это сделать. На мой взгляд, в интернете слишком много уделяется внимания тому, как надо покупать «облака» (дальше буду без кавычек), а не тому, как их использовать, создавать или как они устроены. Дескать, это сложная наука, подвластная только крутым специалистам с кучей дипломов. Ну или интеграторам с такими специалистами в штате. Стоимость подобных облаков обычно получается какая-то негуманная. А если упомянуть про про bigdata, DWH и прочие слова из буклетиков, то к ценнику добавляется нолик-другой.

На самом деле, все не так страшно и я попытаюсь доказать вам это. Может быть даже с примерами и рисуночками.

И да, обычное предупреждение: я рассказываю на основе своего опыта и могу быть неправым от и до. Но вроде созданные системы выполняют свои задачи и жужжат совершенно по делу.

Для начала надо определиться, что же такое облако и с чем его можно есть.

Для ИТшников это куча физических серверов, которые с помощью какой-то системы крутят много сервисов. Сервисам выделяются ресурсы по необходимости или по требованию. Сервисы могут мигрировать с сервера на сервер, размножаться или уничтожаться. Или говоря другими словами, обычный набор железок, который можно встретить в любой серверной.

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

Всякие слова про масштабируемость, отказоустойчивость и прочее можно оставить маркетингу. Методы реализации этого великолепия известны очень давно и облака ничего нового в этом плане не открыли, а просто сильно упростили.

Как-то грустно получается, не находите? Почему же облака так стали популярны? Дело в том, что появились новые методы использования доступных мощностей. И как раз они основаны на сильном упрощении процесса обеспечения тех самых «масштабируемостей», «отказоустойчивостей» и прочего.
В итоге грань между «отказоустойчивым кластером» (масло маслянное, да) и «облаком» получилась … ну очень тонкой. Поэтому предлагаю оставить теологические споры диванным аналитикам и перейти к практике.

Что можно получить от облака?
– Снижение расходов на обслуживание бизнеса. Как прямых, вроде стоимости серверов, так и косвенных, в виде ускорения каких-либо бизнес-процессов.
– Увеличение доступности сервисов. Выйти на «5 девяток» по-прежнему дорого, но гораздо дешевле, чем это было лет пять назад.
– Открытие новых возможностей для бизнеса. Звучит слишком рекламно, но это реально так. Новые технологии реально дают такие возможности, даже заикание о которых раньше приводило к кручению пальцем у виска.

Остальные преимущества в принципе либо укладываются в эти пункты, либо проистекают из них. Давайте я попробую раскрыть эти пункты на примере наиболее распространенных решений.

Для начала про повышение надежности и снижение стоимости. Откуда это получается? Во-первых, обслуживать настроенные однотипно сервера гораздо проще, чем обычный зоопарк. Одни и те же версии программного обеспечения, одно и то же железо. Это дает выигрыш как во времени работы инженеров, так и позволяет получать скидки от вендоров. Во-вторых, возможность вывести любой сервер из кластера для обслуживания. Просто даем команду системе виртуализации убрать с него все сервисы и спокойно занимаемся необходимым. Тем более такую команду может дать и система мониторинга в случае превышения каких-либо значений типа температуры процессора или скорости вращения вентиляторов. И в-третьих, система мониторинга может дать и другую команду: добавить ресурсов «задыхающемуся» сервису. Думаю, любой ИТшник сразу же найдет кучу применений этим возможностям.

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

Вот я тут упомянул публичные и гибридные облака. Чем они отличаются? Публичное облако – это такое облако, все сервисы которого крутятся у провайдера. Гибридное – это «размазанное» по своим и провайдерским мощностям.

Теперь немного про популярные слова, которые связаны с облаками. И которые связывают с преимуществами для бизнеса.

Вот скажем bigdata. Что это? Я встречал определения типа «это то, для обработки чего не хватит даже самого мощного компьютера» и «петабайты данных». Я сторонник другого, более крамольного определения.Bigdata – это те данные, которые у нас уже есть, но мы не знаем, что с ними можно сделать. А потерять не охота. У кого-то это будет мегатонны логов пользователей, у кого-то куча данных с датчиков а у кого-то это будет жалкая пара терабайт картинок. И вот облака дают возможность как-то хранить и по возможности обрабатывать эти данные. При этом бигдачность системы вовсе не характеризуется объемом обрабатываемых данных. Есть системы, где обрабатываются буквально гигабайты данных, но эти гигабайты легко грузят сотни серверов. В общем, красивое слово.

VDI. Или Virtual Desktop Infrastructure. Развитие идеи терминальных серверов, только с предоставлением пользователю своей виртуальной машины. Шикарно ложится на облака, особенно в случае применения однотипных АРМов и поэтому в последнее время развивается очень сильно.

DWH или Data WareHouse. Еще одно общее слово. Для кого-то это хранилище кучи файлов, кто-то хранит всякие таблички. Говоря кратко, это то место, куда бегают всякие система анализа и отчетов за данными. Данные там собираются из разных источников, приводятся к общем знаменателям, группируются и так далее и тому подобное. По понятным причинам DWH очень любят всякие финансовые компании.

Ладно, хватит красивых слов, тем более, что интересующиеся могут спокойно напрячь поисковик и начитаться по любому интересующемуся термину. Пойдем практиковаться.

Планируем облако.

Что надо сделать в самом начале? В самом начале надо взять за шкирку вашего системного аналитика … как нету аналитика? Тогда берете за шкирку себя и начинаете описывать и считать.

Берете каждый сервис в вашей инфраструктуре и все обдумав, отвечаете на следующие вопросы:

– Время работы сервиса. Круглосуточно, ночью, днем в рабочие часы. Бухгалтерия ночью не работает, а веб-сайт должен быть доступен круглосуточно.

– Доступность сервиса. Может ли он делать паузы во время работы? Скажем на 5 минут? Телефония должна работать всегда, а вот резервное копирование может и постоять на паузе.

– Критичность сервиса. Если он «упадет», как сильно это повлияет на бизнес? Сравните бухгалтерию во время сдачи отчета и внутренний портал. Если добудете цифры в духе «простой 5 минут – 100500 рублей» или «день простоя – штраф в мульен», то вообще отлично. Хинт: заручитесь одобрением финансистов и бухгалтеров: они тают, когда ИТшники их спрашивают про их тяжелую долю и пытаются ее облегчить.

– Ресурсные требования по времени. Телефония требует ресурсы пиками и очень не любит, когда ей недодают ресурсов вовремя этого пика. А тот же веб-сервер толерантен к таким проблемам.

– Просто ресурсные требования. Сколько дисков-процессоров-сети надо сервису.

– Сложность обслуживания? Сколько ИТшников в среднем требуется для обслуживания этого сервиса. Стоимость ИТшника?

– Есть ли возможность прогнозировать нагрузку? Для веб-сайта – нет, а для той же системы резервного копирования – запросто.

– Зависимость сервиса. Скажем, бухгалтерия не выживет на одном офисе без бухгалтерской системы, ей будет очень плохо без сервиса печати, чуть полегче без телефонов и ей абсолютно будет начихать на веб-сайт. Но все умрет без работающей системы хранения данных.

– Возможность вынести сервис наружу. Веб-сайт и почтовые системы – почему бы и нет? Бухгалтерию – убьют.

– Уровень масштабирования в зависимости от роста компании. Веб-сайту пофиг, сколько у вас сотрудников, а той же VDI или почтовой системе – нет.

– Сложность масштабирования системы в зависимости от нагрузки. Веб-сайты обычно довольно легко сделать масштабируемыми, а вот телефонию без бутылки не отмасштабируешь. Тут очень хорошо подумать, а какие функции этого сервиса можно отдать наружу.

При этом очень желательно максимально детализировать сервисы. Скажем типичный веб сервис на самом деле состоит из кеширующего сервера, веб-сервера, сервера базы данных и сервера хранения данных. Чем более высокой будет детализация, тем в дальнейшем будет проще.

Это очень нудная, сложная и муторная работа (хотя и должна быть сделана в рамках ITIL/ITSM). Но в качестве утешения я вам обещаю, что вовремя или после процесса вы обнаружите кучу интересных вещей, которые были раньше скрыты.

Кстати, рекомендую сразу же вооружиться чем-нибудь типа visio (или хотя бы листочком с бумагой, но лучше visio) и сразу зарисовывать получаемые ответы. Я рисовать не буду, ибо мне попросту жалко своего времени, ибо это работа огромная и впустую ее делать лень.

Но на данном этапе я повангую и скажу сразу: больше всего линий пойдут к двум сервисам – сервису передачи данных (он же обычно обзывается «локалкой») и к сервису хранения данных (он же жесткий диск, он же файлопомойка, в некоторых случаях это будет NAS).

Следующим по числу «использований» будет сервер баз данных. Но большая часть будет с двумя линиями – к серверу приложений и к хранилищу данных. Зато этих серверов баз данных будет много. Веб-сервер, бухгалтерия, мониторинг, чертлысый – и везде какой-нибудь да серверок будет.

В принципе, уже полученную схему можно распечатывать и вешать на стенку. Непосвященные люди будут впечатляться и водить пальцами по бумаге, отслеживая линии.

Теперь настала пора взять в руки краски и любым приятным способом раскрасить сервера по критичности для бизнеса. При этом рекомендую брать как минимум два цвета: один для «критичный всегда», а второй для «критичный только в рабочее время». Скажу сразу, если у вас получилось, что все сервисы «критичные всегда», то что-то вы не так сделали. Весь мой опыт говорит о том, что так не бывает. Понижайте градус критичности.

Затем закрашивайте тем же цветом те сервисы, от которых зависит данный сервис. Скажем, если вы пометили, что телефония у вас критичная, то следом должны стать критичными «интернет», «локалка», «фаерволл», «сервер данных о пользователях» и стораджи, на которых все это лежит. Ведь без любого из этих сервисов телефония попросту не будет работать. Скажем, отнимаем интернет или фаерволл – перестаем принимать звонки из внешнего мира. Убираем локалку – пользователи перестанут получать звонки. При закраске необходимо строго соблюдать уровень критичности по повышению – если сервис «критичен всегда», то он не может быть перекрашен или зависим от «критичен только в рабочее время».

Данный процесс очень напоминает настройку сервисов в системе мониторинга или для change management из ITSM, поэтому эта работа или уже сделана или должна быть сделана. Поэтому в любом случае работа не будет сделана впустую.

Следующим шагом необходимо изучить у критичных сервисов механизм масштабирования и его стоимость. Где-то будет все просто: добавляем кучку однотипных сервисов и все будет в порядке. А где-то дешевле ограничиться добавлением аппаратных ресурсов. Тут можно покрасить разным цветом рамки или еще как-нибудь разделить «хорошо масштабируемые» от «плохо».

И я очень надеюсь, что вы использовали visio или что-то подобное. Для понимания текущей ситуации очень полезно сгруппировать сервера по критичности/доступности/расположению (как вам больше нужно).

И наконец, последний шаг. Считаем себестоимость каждого сервиса. Скажем, сколько стоит нам веб-сервер сейчас? А если его в локальный кластер? А сколько будет стоить, если его унести на арендованный у провайдера сервер? А если под него купить облако? Есть ли загружаемые с веб-сервера большие файлы, под которые дешевле будет купить сервис CDN? Есть ли разница в стоимости лицензий для «standalone» и «cloud/terminal»? Если мы уменьшим время простоя, то сколько сэкономим?

В результате у вас получится большая портянка, по которой будет сразу понятно, какой сервис выгодно тащить в облако, для какого лучше построить локальный кластер (и какими ресурсами он должен обладать), а какие реализовать по остаточному принципу или вообще оставить на отдельных машинах.

Теперь необходимо причесать картинку и полученную табличку, чтобы получить практически непотопляемые аргументы для любого совета директоров/ акционеров/ финансистов/ ещекого. Эти люди по роду своей деятельности очень любят картинки, которые подкреплены реальными цифрами.

Наиболее внимательные сразу отметят один очень важный момент, который вроде нигде не упомянут: а как выбирать систему виртуализации? Ведь ее тоже необходимо закладывать в бюджет.

Скажу сразу, выбирать систему виртуализации еще рано, в следующей части будем. Вы для начала докажите себе и владеющим деньгами людям, что это вообще выгодно будет. Для предварительных расчетов можете смело ставить стоимость системы виртуализации в 300 баксов на один железный сервер. Этого при необходимости хватит на корпоративную и пальцатую VMware, но скорее всего можно будет обойтись гораздо меньшими деньгами. Лучше побольше заложите на инженеров. Чем он будет более «продвинутей», тем больше шансов, что у вас все взлетит.

И да, картинку спер из интернета. Автора не знаю, а то бы написал.

Что нести в облачный офис?

Итак, несмотря на мои страшилки в предыдущих постах, вы все-таки решили использовать “облака” в своей деятельности. Хоть чуть-чуть, но использовать. Как выбрать то, что стоит нести в облака, а что не стоит?

Для этого есть несколько методик, ниже я попробую объяснить наиболее … подходящие, что ли.

Методика первая, пусть будет “секрет полишинеля”. В соответствии с ней в облако может отправиться любой сервис, который использует данные из внешнего мира или отдает их туда. Под это определение прекрасно подходят такие сервисы, как электронная почта, телефония и веб-сайт.

“Ну ладно, веб-сайт понятно, а как же с почтой и телефоном? Их смогут читать/слушать чужие люди?”. Да, при наличии соответствующих навыков или всяких судебных решений их и так будут читать и слушать чужие люди. Если говорить про телефон, то на операторе (тот, который выдал вам телефонный номер) уже стоит система, позволяющая прослушивать все телефонные разговоры, проходящие через него. А что касается внутренних переговоров, то они в большинстве случаев абсолютно никому не интересны и способны забить любой сервер. То же самое касается и почты. Буквально пара команд у провайдера, который предоставляет вам доступ в интернет, как весь ваш трафик оказывается у него как на ладони. И не обольщайтесь насчет страшных слов SSL/TLS – в подавляющем большинстве случаев все вскрывается так же легко, особенно при наличии административного ресурса. Правда, вынужден добавить ложку меда: по разговорам со знакомыми, такое используют очень редко, ибо во-первых, принцип “неуловимого джо” никто не отменял, а во-вторых, через налоговую сделать все необходимое гораздо проще.

Следующая методика “берите все, что нам негоже”. Тут в облака отправляются данные, которые вам не нужны прямо сейчас или которые нужны всем. Тут главное установить принцип, насколько эти данные вам не нужны. Скажем, данные от систем резервного копирования вам именно сейчас не нужны, занимают много места и хранение их рядом с резервируемыми системами прямо противоречит всем нормам. Так зашифруйте их посильнее и пусть лежат где-нибудь в Америке. Что касается данных которые нужны всем: зачем устраивать на своем сервере каталог “для скачки”? Ролики, дистрибутивы программ и прочие подобные штуки с удовольствием примут к себе системы CDN. Будут довольные и пользователи, которые будут скачивать необходимое им быстро и Вы, так как канал до вас (или вашего сервера) не будет загружаться.

И наконец, в облака удобно/выгодно отправлять то, что относится ИТшному понятию R&D. Говоря кратко, то, что запускается “на посмотреть”, меняется по двадцать раз на дню и наполняется тестовыми или сильно устаревшими данными.

Теперь про данные, которые нельзя отправлять в облака. Понятное дело, Вы сами сможете определить список того, что позволить прочитать другим нельзя. У кого-то это будет бухгалтерия, у кого-то данные о техпроцессе, в общем, у каждого свое. Тут надо просто садиться и разбираться.

Но (по крайней мере для России) есть одна категория, которую нельзя отправить в “облако”: персональные данные. Говоря простыми словами туда попадает все от паспортных данных и места проживания и до всяких медицинских анализов и выписок. Нельзя не потому что не получится, а потому что “атата, если обнаружат”: ни одно известное мне “облако” не использует сертифицированных средств защиты информации. Вроде в России потихоньку начали появляться провайдеры, которые обеспечивают обработку персональных данных, но там от облаков только название, да и ресурсы, которые они могут предоставить, вызывают лишь недоумение.

А теперь абзац неприкрытой рекламы меня любимого: мне нравятся “облака” и я готов совершенно бесплатно (конечно, не откажусь и от оплаты, если предложите 🙂 ) поконсультировать/помочь/рассказать как сделать по поводу “облаков”. Просто из любви к теме. Я не связан с каким-либо провайдером или сервисом “облаков” или производителем систем виртуализции, поэтому мне абсолютно начхать на маркетинговые заморочки. Пишите письма на multik@multik.org, в skype пользователю kiltum или оставляйте комменты.

Дорогие мои облака …

В прошлый раз я обещал на пальцах показать, что облака дороже, но они дешевле. В принципе я уже писал про это, но это было давно и не правда.

Наверняка вы уже задумывались о использовании “облаков” в своем бизнесе, но простые расчеты на калькуляторе и консультации с ИТшниками неизменно приводили к обескураживающим результатам: стоимость аналогичного, но “облачного” сервиса неизменно оказывалась в 1,5-2 раза выше. Как же так? Ведь вон сколько компаний использует облака в своей работе и рапортуют о снижении расходов … А тут ИТшники опять начинают свою вечную волынку про недостаток серверов … Что делать?

Что бы не быть голословным, возьмем для примера небольшую компанию, чья инфраструктура построена на классических принципах. Давайте посчитаем, сколько серверов надо. Ну и заодно прикинем на пальцах стоимость каждой железки.

1. Фаирволл. Он же брэндмауэр. Штука, которая выпускает вас в интернет, фильтрует лишнее и иногда служит HR-инструментом под названием “на какие сайты ходят сотрудники”. Хватит 50 тыщ.
2. Почтовый сервер. Без почты нынче никуда. Тут лучше заложить где-то в районе 100 тыщ.
3. Веб-сервер. Сайтик обычно много нагрузки не требует, поэтому тоже 50.
4. Сервер телефонии. Положим те же 50 тыщ.
5. Сервер бухгалтерии. Бухгалтера люди нервные, поэтому 100 тыщ и не надо экономить.
6. Файлопомойка. Сотрудникам надо файликами обмениваться. Возлагать это на почту – моветон. Тыщ 80 надо.
7. Резервное копирование. Есть компании, где уже теряли данные, а есть, где еще только будут. Тыщ 100.

Для начала хватит. Конечно, в реальности часть функций обычно объединяется на одном сервере, но у нас админ печется о безопасности, поэтому старается разнести все. Ну и в разных компаниях добавляются другие сервера: для разработки, тестирования и прочих штук. Но я их учитывать не буду.

Итого получается в районе 550 тысяч рублей. Эти 7 коробок жрут электричество, требуют охлаждения, запасных частей и квалифицированного присмотра. Через некоторое время их мощности начинает не хватать и начинаются узаконенные репресии пользователй в духе “более 500 мегабайт в почтовом ящике не хранить” и “бухгалтерия тормозит, потому что в сервере винт сдох” (хорошо, что тормозит. у некоторых просто падает). Знакомо?

Что делать? Бизнес растет, но на одних серверах разориться же можно … И тут в дело вступает хороший, качественный ИТшник. Срываю так сказать, покровы. Для начала: одиночные сервера никогда не загружены на 100%. Из-за разных там особенностей больше 60-70% нагрузку поднимать попросту нельзя: будет все ломаться.

Сначала составляют список серверов (у нас он выше) и характер их загрузки. Например, сервер бухгалтерии и файлопомойка ночью не используется. А вот сервер резервного копирования наоборот, ночью загружен по самое выше некуда. А вот почта и телефония ночью тоже не загружены, но работать должны всегда.

Отсюда вытекает вполне логичное предложение: почему бы серверу резервного копирования не поделиться днем своими ресурсами? А серверу бухгалтерии и файлопомойки ночью? С использованием современных технологий – легко.

Сам процесс объединения стайки серверов в “облако” я пропущу. Вам это во-первых попросту неинтересно, а во-вторых, там слишком много нюансов, описанию которых пришлось бы посвятить много места.

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

Вам же главное знать то, что у вас теперь есть свое “облако”. Персональное, частное – называйте как хотите.

Что вы получаете?

– Возможность продать один-другой сервер. Подчеркиваю – возможность (ИТшники просто так не выпустят из своих рук 🙂 ). Ибо если одиночные сервера нельзя грузить на 100%, то в “облаке” вполне.
– Более высокую доступность серверов. Теперь в случае поломки одного из “железных” серверов есть возможность попросить “пододвинуться” другие, пусть и за счет уменьшения скорости работы.
– Возможность отдавать более мощный сервер (у нас же сервера не одинаковые изначально) на более необходимую сейчас работу. Скажем, днем самый мощный сервер будет помогать процессу сдачи бухгалтерского отчета, а ночью обрабатывать данные для системы резервного копирования.
– Более разумно распределять нагрузку. Скажем, отобрать ночью у почтового сервера ресурсы процессора в пользу других. Пусть письмо ходит не 1-2 секунды, как днем, а 10-20. Кому какая разница?

А теперь о более приятном. Если делать подобное с “нуля”, то более высокую производительность и бОльший запас по мощности всего комплекса можно получить с помощью пары серверов, каждый из которых стоит по 200тр. И эти серверы будут жрать меньше электричества, меньше греть окружающую среду и требовать меньший уход. 150 тысяч экономии прямо “в лоб”!

Но это “частное облако”. Как же можно заработать или сократить расходы с помощью публичных облаков?

Для начала можно легко увеличить безопасность вашего бизнеса. Не знаю как в других странах, но в России до сих пор не изжили “изъятие вещественных доказательств”. С одной стороны, счет не заблокирован и на нем есть деньги, а с другой – все данные остались на тех самых “вещественных доказательствах”. Вот для примера бухгалтерия. Объемы базы данных очень редко превышают еденицы гигабайт. Вот возьмите и дайте задачу, что бы система резервного копирования попутно заливала данные еще и туда. Для безопасности – хорошо зашифрованными. Сейчас стоимость хранения одного гигабайта на S3 – $0.03 в месяц. Да, я не ошибся – три цента за гигабайт в месяц. Добраться до архивов можно будет с любого компьютера, подключенного к интернету, а уж что с ними делать – дело ваше. Сравните со стоимостью хранения подобного где-нибудь на стороне “обычным” способом.

Затем рассмотрите свои бизнес-процессы и выделите те, которые требуют непродолжительных, но больших компьютерных ресурсов. Скажем, в каком-нибудь рекламном агенстве это может быть процесс рендеринга роликов. Покупать для этого отдельный мощный сервер, который будет 90% времени пинать балду – не выгодно. А без него никак. Куда лучше за $3 в час арендовать гораздо более мощный сервер в облаке и использовать его только тогда, когда надо. И кто мешает арендовать не один сервер, если роликов много?

Надо изредка рассылать большие объемы писем (и которые ни разу не спам)? Вон, SES берется доставить со всеми заморочками тысячу писем за 10 центов. Стоимость обычного почтового сервера, способного переварить хотя бы 20-30 тысяч писем за час, предлагаю узнать самостоятельно.

И так далее и тому подобное. Везде, где требуются большие объемы, гораздо дешевле воспользоваться мощностями гигантов, чем пытаться сделать свое и на коленке.

И наконец, можно заранее подготовиться к приятным, но внезапным неожиданностями. Для примера можно подготовить все необходимое, что бы ваш веб-сайт смог выдержать любой поток посетителей. В обычные времена ваш веб-сайт крутится у вас за стенкой. Но стоит возрасти нагрузке (скажем, отдел рекламы провел успешную компанию), как ваш веб-сайт сначала переездет к провайдеру (что бы не загружать ваш канал в интернет), а при дальнейшем повышении нагрузки начнет поднимать у провайдера свои копии. И так до тех пор, пока весь поток посетителей не схлынет. Схлынул – сайт вернулся в родные пенаты. Не верьте мне, просто возьмите калькулятор в руки и подсчитайте стоимость подобного решения. Если у вас подобные случаи случаются регулярно, то вы будете очень обрадованы открывшимися возможностями.

И подобных возможностей в каждой компании – уйма. Честно.

Если все так хорошо, то почему все так плохо? Во всем этом есть одна большая ложка дегтя: без квалифицированных специалистов подобное реализовать нельзя. В смысле реализовать можно, но вы скорее потеряете деньги, чем сэкономите. И пока технологии “молодые”, нет никаких сертификатов, лицензий и прочих документов, свидетельствующих о том, что тот или иной ИТшник умеет “нырять” в облака и что более важно, “выныривать” из них …

А таких – мало.

Облака, белогривые лошадки …

… или о облаках простыми словами.

Покупайте наших слонов, теперь и в облаках! Самые облачные облака по выгодным тарифам!

Такое или примерное такое сейчас можно увидеть и услышать в любой рекламе услуг, связанных с компьютерами. Что же такое облака и чего с ними можно делать?

Для начала маленький экскурс в историю. Давным-давно компьютеры умели выполнять только одну задачу за раз. И если он начинал считать, сколько будет 2+2, то нипочем не хотел останавливаться. Потом компьютеры научили делать сразу несколько задач. Они могли одновременно считать сколько будет 2+2 и спрашивать у пользователя, сколько ему лет. Потихоньку увеличивая мощность компьютеров дошли до того, что один мощный компьютер мог представляться для окружающих кучей слабых. Ведь для очень многих задач куча слабых компьютеров гораздо удобней и выгодней одного, но очень мощного.

Но тут пришли продавцы и маркетологи. Первым надо было увеличить продажи, а вторые помогали первым, ведь им тоже перепадал кусок пирога.

Поначалу шаги было очень осторожными. Практически все шло под лозунгом “сократи расходы на сервера”. Ведь в самом деле, поставить и обслуживать один мощный сервер гораздо дешевле, чем кучку маленьких. Тут и стали называть эти маленькие сервера виртуальными. Ведь их нельзя пощупать, но они есть. Постепенно технологии дошли до того, что стало возможно объединять мощные сервера между собой так, что они могли “делиться” с соседями виртуальными серверами без их остановки. И на всех схемах сети такая конструкция обозначалась облаком. Типа мы знаем, что сервер там, но детали реализации от нас скрыты.

Ушлые маркетологи мгновенно раскопали ассоциацию и начали толкать “облака” в массы. В результате вышеописанное (несколько мощных серверов, которые стоят в серверной у вас за стенкой) стали называть “частное облако” или private cloud.

Тут же появились провайдеры, которые стали предлагать “облака” для всех страждущих. Такие облака стали называть “публичными облаками” или public cloud. Услуга довольно быстро стала популярной: ведь большинству людей не нужны для своих задач мощные компьютеры, а провайдерам очень дорого обслуживать обычные слабые сервера.

Следующим появились на свет “гибридные облака”. Это когда часть виртуальных серверов работает в серверной за стенкой, а часть – у провайдера. А для вас – ну абсолютно никакой разницы, где они размещены. Вы работаете с ними одинаково во всех случаях.

Больше всего “облакам” радовались ИТшники. Благодаря “облакам” у них исчезло очень много нудной работы по обслуживанию серверов … Конечно, появилось много другой работы, но это тема уже для другой статьи.

Итак, в чем же основное преимущество облаков?

– Снижение расходов на серверный парк. По моим прикидкам, переход с классической схемы (один сервис – один сервер) на облачную (много серверов – много сервисов) дает экономию примерно в 20-30% просто от самого факта использования.
– Снижение времени простоя. Теперь для обслуживания “железного” сервера нет необходимости останавливать работу размещенных на нем сервисов.
– Резкое ускорение специфических для ИТ задач. Поднять новый сервер или скопировать работающий – дело минут, но никак не часов.
– Возможность при наличии соответствующих навыков кратковременно и очень резко увеличивать мощность какого-либо сервиса.

Вот за эту особенность и ухватились в очередной раз маркетологи. И как обычно, выкинув самые значимые слова (я про навыки), ринулись на следующий виток. Необходимость как-то разделять “облака” их надолго не остановила и они придумали новые слова.

“Старые” облака (провайдер вам предоставляет один или несколько серверов, возможно объединяя их в одну сеть с вашей) стали называть IaaS (Infrastructure as a service). Инфраструктура как сервис. Легко понимаемая всеми ИТшниками модель. Яркий пример – Amazon

Вон та возможность резко увеличивать мощность (повторюсь, при наличии навыков!) привела к следующему варианту облаков: PaaS (Platform as a service). Платформа как сервис. Пример – Azure. Суть простая. Берет провайдер толковых спецов, которые настраивают какой-либо сервис как надо. А потом продает этот сервис вам. Скажем, у вас есть веб-сайт, на который приходит 1000 человек в день. Ваши маркетологи, продавцы и прочие товарищи что-то такое замутили, что к вам внезапно пришло 100000 человек. Обычно веб-сайт в таких случаях тупо умирает под нагрузкой. В случае PaaS правильно настроенный сервис начинает поднимать для внезапно свалившейся нагрузки еще сервера. Десять, сто, тыщу. В общем пока не переварит весь поток. А потом точно так же берет и “убивает” ставшие ненужными сервера. В итоге все довольны: пользователи увидели ваш сайт, а не сообщение о недоступности, вы получили новые заказы, а провайдер – деньги.

Очень это понравилось маркетологам и они придумали SaaS (Software as a service) или программа как сервис. Оно очень похоже на PaaS, но про отдельный сервис. Скажем, вам нужен почтовый сервер. Можно сказать админу, он купит сервер, настроит его … А можно пойти к провайдеру и купить доступ к его почтовому серверу. Если у вас в компании 100 человек, так и купите кусочек провайдерского сервера на 100 человек. А провайдер пусть уже сам мучается с антивирусами, антиспамами и прочей фигней. Яркий пример – Office 365.

Но тут внезапно обнаружилось, что SaaS один-в-один повторяет то, что предлагается уже много лет. В самом деле, купить кусок сервиса можно было очень давно. И Вам совершенно безразлично, на каких там технологиях крутится.

Думаете это кого-то остановило? Неа, просто стали продавать старое под новым соусом.

И для резюме нужно подвести итоги. Сравним их с привычной всем “своей серверой”

Преимущества:
– Быстрота развертывания. При наличии денег на карточке можно получить полностью готовый сервер или сервис за десятки минут. Причем в стране на выбор.
– Более высокая доступность. У провайдеров просто больше возможностей это обеспечить.
(ТОЛЬКО для частных облаков) – Более низкая стоимость обслуживания

Недостатки:
– Более высокая стоимость обслуживания. На данный момент – в 1,5-2 раза дороже. За тренд надо платить.
(для всех КРОМЕ частных облаков) – Полная потеря контроля за вашими данными. Что бы там не писали маркетологи в пресс-релизах и зазывалках, данные из облака очень легко (по сравнению с классической схемой) могут быть взяты без возможности какого-либо контроля с вашей стороны. Люди, которые имеют доступ к физическим серверам, всего лишь люди.

Тут обычно возникает мысль про то, что я (в смысле автор) ничего не понимаю. Ведь если “облака” стоят дороже, то почему ими пользуются? Люди же не настолько глупые …

Но где можно “выиграть в облаках”, я напишу в другой раз. Вдруг никому не надо и я только зря клавиатуру терзал? 🙂