По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данный момент на рынке представлено большое количество таких технологий виртуализации, как, например, OpenVZ, KVM и Xen. Вы, должно быть, встречались с этими терминами, если пытались купить виртуальный частный сервер (VPS). В статье мы сравним эти три технологии с точки зрения покупки VPS, чтобы вы могли выбрать наиболее подходящую вам технологию.
Обзор Виртуализации и Контейнеризации
Виртуализация – это технология, которая позволяет вам создавать несколько виртуальных машин (ВМ) на одном аппаратном обеспечении. В свою очередь каждая виртуальная машина представляет собой физический компьютер, на который вы можете установить операционную систему. Работу виртуальных машин контролирует гипервизор, который предоставляет им хостовые системные ресурсы: процессорные, оперативной памяти и устройств хранения.
Все ВМ изолированы друг от друга, то есть программное обеспечение одной ВМ не имеет доступ к ресурсам другой ВМ. Многие провайдеры VPS устанавливают гипервизор на физический сервер и предоставляют пользователям виртуальную машину в качестве виртуального частного сервера (VPS).
Контейнеризация сильно отличается от виртуализации. Вместо гипервизора на хост-систему устанавливается операционная система, на которой вы можете создавать «контейнеры». Внутри контейнеров вы можете создавать приложения, и уже ОС позаботится о выделении ресурсов каждому контейнеру. В этом случае ядро операционной системы и драйверы являются общими для всех контейнеров.
Таким образом, контейнеризация зависит от ОС. И, соответственно, в контейнере можно запускать только те программы, которые соответствуют хостовой ОС. Например, если контейнеризация работает на Linux как на хостовой ОС, внутри контейнера вы можете запускать приложения только на Linux. В этом отличие от виртуализации – в виртуальной машине вы можете запустить любую ОС и, соответственно, любое приложение. С другой стороны, контейнеризация намного более эффективна, чем виртуализация, так как не затрачивает лишнюю энергию на запуск ОС в каждой виртуальной машине.
В этой статье мы уделим внимание системной контейнеризации. Такой вид контейнеризации позволит вам запускать ОС внутри контейнера. Несмотря на это, ядро и драйверы по-прежнему являются общими для различных операционных систем внутри каждого контейнера.
Xen и KVM являются технологиями виртуализации, а OpenVZ – это технология контейнеризации на базе Linux.
OpenVZ
OpenVZ (Open Virtuozzo) – это платформа контейнеризации, базирующаяся на ядре Linux. Она позволяет на одной хост-системе запускать несколько ОС, также базирующихся на Linux. Контейнеры работают как независимая система Linux с правами доступа уровня root, изоляцией на уровне файлов, пользователей или групп, процессов и сетей.
Провайдеры серверов предоставляют контейнерам OpenVZ некоторое количество оперативной памяти, процессорных ядер и места на жестком диске и продают их в качестве виртуальных серверов Linux. Какая-то часть ресурсов ЦП и памяти выделена контейнеру, а какая-то часть ресурсов “разрывается”, то есть если контейнеру требуется больше ресурсов помимо того, что ему было выделено, он может временно заимствовать их из неиспользуемых ресурсов других контейнеров.
Так как при контейнеризации ядро является общим для всех контейнеров, изменить настройки ядра, обновить его или использовать дополнительные модули ядра невозможно. К моменту написание этой статьи большинство провайдеров используют OpenVZ 6 на базе Linux 2.6. Таким образом, вы не сможете улучшить функционирование системы и возможности ядра за счет обновлений. У вас так и останется старый дистрибутив Linux. И вы не сможете установить Docker или использовать утилиты ipset и nftables.
OpenVZ 7 – это самая последняя версия проекта с обновленным ядром. Однако очень немногие провайдеры предоставляют ее из-за сложности установки и нехватки вспомогательных инструментов.
В заключение, с точки зрения провайдера систему OpenVZ легко конфигурировать и запускать, в отличие от KVM и Xen. И так как это система на контейнеризации, она затрачивает намного меньше энергии, вследствие чего провайдеры могут предоставлять большее количество VPS с одного физического сервера.
Xen
Xen – это платформа виртуализации с открытым исходным кодом, которая первоначально начиналась как исследовательский проект в Кембриджском университете. В настоящее время в разработке проекта участвует Linux Foundation.
С помощью различных инструментов провайдер предоставляет виртуальным машинам Xen фиксированный объем оперативной памяти, процессорных ядер, места на жестком диске и IP-адресов и предлагает их в качестве VPS.
В целом гипервизоры делятся на два типа: 1 и 2. Гипервизор типа 1 работает непосредственно на хост-оборудовании, в то время как гипервизор типа 2 зависит от базовой операционной системы. Xen относится к гипервизору первого типа.
Так как Xen – технология виртуализации, созданные на ее основе ВМ могут работать на любой ОС, включая Linux, Windows и BSD. А поскольку каждая ВМ работает на своей операционной системе, вы можете обновить ядро, изменить его настройки или использовать дополнительные модули ядра.
Установка виртуализации несет за собой большой расход энергии на эмуляцию определенных аппаратных функций, а также на запуск операционной системы. Чтобы уменьшить расходы, Xen использует технику "паравиртуализация". В этом случае гипервизор использует альтернативные способы выполнения одних и тех же аппаратных операций более эффективным способом. Если гостевая ОС знает, как использовать эти альтернативные интерфейсы, она делает “гиперзвонок”, чтобы поговорить с гипервизором. Этот режим работы называется Xen Paravirtualization (Xen-PV).
Когда гостевая ОС поддерживает паравиртуализацию, используется другой режим виртуализации – Xen Hardware Virtual Machine (Xen-HVM). В этом случае Xen использует программу QEMU, чтобы обеспечить эмуляцию аппаратного обеспечения. Чтобы использовать Xen-HVM, аппаратная виртуализация должна быть обеспечена хост-системой.
KVM
KVM (Kernel Virtual Machine) – это модуль ядра Linux, который предоставляет платформу для сторонних инструментов (таких как QEMU) для обеспечения виртуализации. Поскольку это модуль ядра, KVM повторно использует многие функции ядра Linux для своих целей.
С точки зрения конечного пользователя Xen похож на KVM, поскольку он позволяет запускать любую ОС и работать с низкоуровневыми настройками ядра. Провайдеры серверов используют сторонние инструменты для создания виртуальных машин с фиксированным объемом оперативной памяти, ядрами ЦП, пространством жесткого диска и IP-адресами и предлагают их в качестве виртуальных машин. Иногда провайдеры VPS, использующие KVM, предоставляют пользователю возможность загрузить свой ISO-файл для установки на VPS.
KVM работает только на оборудовании, поддерживающем аппаратную виртуализацию. Подобно Xen, KVM также обеспечивает паравиртуализацию для устройств ввода-вывода через API «virtio».
Что же выбрать?
Выбор платформы зависит исключительно от ваших предпочтений. Если вы не хотите тратить много денег на Linux сервер и вас не беспокоит старая версия ядра и невозможность пользоваться такими программами, как Docker, то выбирайте OpenVZ. Если вам нужна еще другая ОС, например, Windows или вы хотите использовать обновленное ядро Linux, выбирайте KVM или Xen.
Многие провайдеры используют возможность OpenVZ «разрываться» и перегружают свои системы, вмещая как можно больше серверов на один хост. В случае, если слишком много серверов будет пользоваться центральным процессором и памятью одновременно, вы заметите значительное снижение уровня производительности своего сервера.
Есть провайдеры, которые рекламируют свои KVM и Xen как «специализированные ресурсы», но, к сожалению, это тоже не всегда правда. И KVM, и Xen предлагают функцию «раздувания памяти» («memory ballooning»), при которой ваша оперативная память может быть востребована другим VPS. В каждом VPS установлен драйвер (Balloon Driver), который помогает в этом процессе. Когда гипервизор забирает память у вашего VPS, создается впечатление, что драйвер не дает пользоваться вашей памятью. Однако VPS никогда не сможет получить больше памяти, чем ему было изначально выделено.
Таким образом, перегрузка возможна в случае со всеми тремя платформами. Однако провайдеры KVM/Xen перегружают их намного меньше, чем OpenVZ, из-за технических ограничений системы, основанной на гипервизоре.
Чтобы определить производительность сервера перед покупкой, следует пройти тест производительности (бенчмарк) с помощью приложений: bench.sh, speedtest-cli или Geekbench. К тому же, прежде чем покупать VPS, основанный на одной из технологий – OpenVZ, KVM или Xen, лучше сравнить цены и прочитать комментарии о компании. У провайдера с заниженными ценами или плохой репутацией независимо от технологии будет низкая производительность VPS.
Почитатей первую часть статьи про траблшутинг NAT/PAT на Cisco.
В этой части мы рассмотрим проблемы DHCP.
Урок 1
Вот новый сценарий, позвольте мне сначала объяснить его:
Зеленая зона - это наша локальная сеть, так что это наш NAT inside.
Красная область - это Интернет, поэтому это наш NAT outside.
Предполагается, что хост - это компьютер с шлюзом по умолчанию 192.168.12.2.
Наш маршрутизатор NAT подключен к маршрутизатору ISP.
Маршрутизатор ISP назначил нам подсеть 172.16.1.0 / 24, которую мы собираемся использовать для трансляции NAT.
BGP был настроен между NAT и маршрутизатором ISP для доступа к сети 192.168.34.0/24.
Предполагается, что веб-сервер прослушивает TCP-порт 80 и использует 192.168.34.3 в качестве шлюза по умолчанию.
Однако пользователи нашей локальной сети жалуются на то, что не могут подключиться к веб-серверу. Давайте проверим нашу конфигурацию NAT:
Мы можем убедиться, что трансляция работает:
Inside local IP-адрес нашего хоста.
Inside global находится один из IP-адресов из нашей подсети 172.16.1.0/24.
Outside local and global IP-адрес нашего веб-сервера
Эта трансляция выглядит хорошо, потому что все IP-адреса верные.
Мы видим, что маршрутизатор NAT научился достигать сети 192.168.34.0 / 24 через BGP.
Наш NAT-маршрутизатор может подключаться к веб-серверу, поэтому проблема с подключением отсутствует. Однако следует помнить одну важную вещь. Пакет IP, который производит маршрутизатор NAT, выглядит следующим образом:
IP-адрес получателя является нашим веб-сервером, и с ним нет проблем. Исходный IP-адрес - 192.168.23.2, и поскольку мы получили ответ, мы знаем, что маршрутизатор ISP знает, как достичь подсети 192.168.23.0 / 24. Это важно, поскольку подсеть 192.168.23.0 / 24 напрямую подключена к маршрутизатору ISP.
Однако, если мы отправляем эхо-запрос с хост-устройства, он преобразуется из-за NAT в IP-адрес в подсети 172.16.1.0/24. Пакет IP будет выглядеть так:
Вот что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправляется маршрутизатору ISP:
Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.
Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!
ISP#debug ip packet 1
IP packet debugging is on for access list 1
ISP#conf t
ISP(config)#access-list 1 permit host 192.168.34.4
Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.
Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.
Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to...it является не маршрутизируемым и будет отброшен.
Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:
NAT(config)#ip route 172.16.1.0 255.255.255.0 null 0
NAT(config)#router bgp 1
NAT(config-router)#network 172.16.1.0 mask 255.255.255.0
Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.
Пинг прошел проблема решена!
Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.
Урок 2
Начнем с простого сценария. Маршрутизатор с левой стороны - это наш DHCP-клиент, а маршрутизатор с правой стороны - это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов ... что может быть не так?
Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.
Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо...
Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.
Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.
DHCPServer#show ip dhcp pool
Мы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.
Мы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает ... что это может значить?
Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.
DHCPServer(config)#service dhcp
Включим сервис.
Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.
Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!
Итог урока: если все в порядке, убедитесь, что служба DHCP работает.
Урок 3
Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP
Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief.
DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown
Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.
Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит...
DHCPServer#debug ip dhcp server packet
Включим отладку, чтобы увидеть, что происходит.
Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?
Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.
Чтобы доказать это, мы можем включить отладку
Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.
DHCPServer(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.
Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.
Если вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Вот и все ... проблема решена!
Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.
3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.
Наверняка кто-то из вас хоть раз в жизни получал SMS после звонка в определенную компанию.
Обычно, это просьба оценить работу операторов. Так, например, это сделано у GSM операторов. Также это может быть SMS с благодарностью за обращение от компании или же об актуальных акциях и предложениях.
Сегодня я хотел бы рассказать о том, как Вы можете реализовать подобную функцию с использованием FreePBX
Статья написана по мотивам существующей на данном ресурсе публикации "Оценка оператора после звонка"
У данного метода есть один недостаток - для его работы нужен chan_dongle и тариф с безлимитными SMS. Для тех, у кого нет пресловутого chan_dоngle, есть другой метод, который я постараюсь объяснить.
Для особо нетерпеливых прошу Вас заглянуть в контакты, возможно, я уже там появился :)
В данном методе мы не будем ломать диалплан FreePBX и использовать тяжелую артиллерию в виде MySQL. Итак, приступим.
Для начала открываем конфигурационные файлы, а именно:
/etc/asterisk/extensions_custom.conf
Вносим в него такой кусочек диалплана. В коде я дал комментарии зачем нужны некоторые части:
[send-sms]
exten => _.,1,NoOp(Start sms)
exten => _.,n,DIAL(SIP/${EXTEN},,trg) ;опция g позволяет "проваливаться вниз". ВНИМАНИЕ агент должен использовать вашу технологию (sip или pjsip)
exten => _X.,n,GotoIf($[${DIALSTATUS}=BUSY]?busy:answered) //проверяем, был ли отвечен вызов, вот здесь мы или пропускаем клиента дальше если с ним уже говорили или нет.
exten => _X.,n(busy),Hangup()
exten => _X.,n(answered),Goto(sms,${EXTEN},1)
[sms]
exten => _X.,1,NoOp(Statrt SendSms)
exten => _X.,n,Answer()
same => n,Set(COUNT=1); установка счетчика. По идее, он тут не нужен, но сделан на всякий аварийный случай. Вдруг заклинит и клиента заспамит смс? :)
same => n,Set(RECIVER=Имя донгла в системе); если используете донгл
same => n,Set(RECIPIENT=${CALLERID(num)})
same => n,Set(TEXT="Спасибо что обратились в нашу компанию Рога и копыта"); текст смс
same => n,GotoIf($["${RECIPIENT:0:2}" != "79"]?end); это проверка на принадлежность к мобильным номерам. Уточните формат входящих CALLERID(num) на вашей АТС - с 7 или 8?
same => n,System(/usr/sbin/asterisk -rx 'dongle sms ${RECIVER} 7${RECIPIENT:1} ${TEXT}'); тут отправка с донгла.
same => n,Set(COUNT=$[${COUNT} + 1]); увеличение счетчика (который не нужен, а вдруг)
same => n,GotoIf($["${COUNT}" > "1"]?end); проверка и отправка на завершение
exten => _X.,n(end),Goto(macro-hangupcall,s,1); Конец
Обратите внимание на пометки в диалплане. В частности, Агент должен использовать вашу технологию подключения. Входящие форматы на ваши транки, 7 или 8. Если он еще не унифицирован, то рекомендую это сделать и привести в норму стандарта E164. Если входящие у вас содержат + то, вместо ${RECIPIENT:0:2} сделайте ${RECIPIENT:0:3}
На этом, настройка конфигурационного файла extensions_custom.conf закончена. Теперь открываем файл queues_post_custom.conf и вставляем туда такую строку:
member=Local/4015781@send-sms/n,0,4015781,hint:4015781@ext-local
Где 4015781 номер существующего Агента в очереди. После этого, закрываем файл, перезагружаем диалплан командой dialplan reload и тестируем.
Применять можно, например, для отправки благодарности клиенту с напоминанием времени работы или адреса компании.
Чтобы не огорчить тех, кто не использует донглы или использует GoIP или другие Gsm шлюзы, на мой взгляд, есть более "красивый" метод:
Идем в один из множества веб сервисов для SMS рассылок (названия писать не буду), регистрируемся у них и берем их готовые библиотеки для доступа к API. Я покажу на примере PHP API одной известной компании:
#!/usr/bin/php -q
<?php
#парсим данные из AGI
require(′phpagi.php′);
$agi = new AGI();
$phone = $agi->request[′agi_arg_1′];
text = $agi->request[′agi_arg_2′];
$sender = ′INFORM′;
// !!! Замените API-ключ на свой.
$apikey = ′XXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZ′;
$url = ′https://smspilot.ru/api.php′
′?send=′.urlencode( $text )
.′&to=′.urlencode( $phone )
.′&from=′.$sender
.′&apikey=′.$apikey
.′&format=json′;
$json = file_get_contents( $url );
echo $json.′′;
$j = json_decode( $json );
if ( !isset($j->error)) {
echo ′SMS успешно отправлена server_id=′.$j->send[0]->server_id;
} else {
trigger_error( $j->description_ru, E_USER_WARNING );
}
Используем AGI. И в представленном диалплане меняем одну строку, а именно:
same => n,System(/usr/sbin/asterisk -rx 'dongle sms ${RECIVER} ${TEXT}'); тут отправка с донгла.
на:
same => n,AGI(sendsms.php, 7${RECIPIENT:1}, "${TEXT}")
И на этом - все. Чем данный способ лучше? Могу точно сказать, что в подобных сервисах для компаний есть возможность в качестве отправителя зарегистрировать название организации – это явно плюс в копилку лояльности клиента :)
Это значит, что не нужен донг и SMS клиенту приходит не с безликих цифр, а от имени вашей компании в поле отправитель. Это, безусловно, повышает доверие и лояльность получателя SMS.
Надеюсь, что данный метод будет полезен и найдёт применение в ваших бизнес-процессах. Удачи!