По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Запись телефонных разговоров на IP – АТС Asterisk является безусловно важной «фичей» для любой организации. С другой стороны, с ростом количества записей уменьшается память на дисках. Рано или поздно, перед организацией встает вопрос об удалении старых файлов, для освобождения места. Мы разработали PHP скрипт, который автоматически удаляет записи разговоров (.wav) и данные в базе данных по этим звонкам старше определенного количества дней. Чтобы адаптировать его под себя, вам нужно просто указать максимальное количество дней для хранения записей.
Скрипт автоматического удаления
Сам скрипт написан на PHP и представляет собой 23 строчки кода. Основная переменная в скрипте - days. Укажите в ней количество дней, которое вы планируете хранить записи:
<?php
$days = 180; //записи, которые старше 180 дней будут удалены. Укажите здесь количество дней для удаления;
$hostname = "localhost"; //если скрипт выполняется на том же сервере, что и IP - АТС Asterisk, то оставьте здесь localhost. В противном случае укажите IP - адрес;
$username = "delete"; //логин для подключения к базе данных asteriskcdrdb
$password = "333jIje45"; //пароль для подключения к базе данных asteriskcdrdb
$dbName = "asteriskcdrdb";
$file = '/home/admin/log_mail.txt';
$cdate = date('Y-m-d H:i:s', strtotime('-'.$days.' days')); //определяем максимальную дату звонка. Все звонки старше этой даты, будут удалены;
$adate = date('Y-m-d H:i:s'); //текущая дата для записи в лог – файл;
/* создать соединение */
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName) or die(mysql_error());
/* удаляем информацию о записях в таблице cdr*/
$query = "DELETE from cdr WHERE calldate < '$cdate';";
$res=mysql_query($query) or die(mysql_error());
/* Как много нашлось строк */
$number = mysql_affected_rows();
/* удаляем сами аудио - записи разговоров */
echo exec('find /var/spool/asterisk/monitor/ -type f -mtime +'.$days.' -exec rm -rf {} ;');
$current = "DELETE :: $adate :: $number records were deleted from CDR
";
file_put_contents($file, $current, FILE_APPEND | LOCK_EX); //записываем запись в лог файл;
?>
Скачать скрипт удаления записей
Загруженный скрипт сохраните в формате .php.
Адаптация скрипта на вашей АТС
Первое, что необходимо сделать, это создать пользователя для доступа к базе данных, который будет иметь права на удаление. Для этого, даем следующие команды:
[root@asterisk]# mysql
mysql>CREATE USER 'delete'@'localhost' IDENTIFIED BY '333jIje45';
Теперь предоставляем необходимые права:
mysql> GRANT DELETE, SELECT ON asteriskcdrdb.cdr TO 'delete';
Готово. Теперь скрипт необходимо запланировать через cron для регулярного выполнения. Даем команду crontab -e и добавляем следующую строку:
*/2 10-18 * * 1-5 /usr/bin/php /home/deletecdr.php
В данном примере, наш скрипт будет отрабатывать каждые 2 минуты с понедельника по пятницу, с 10:00 до 18:00. Здесь, /home/deletecdr.php - полный путь к скрипту. Сохраняем изменения и наслаждаемся спокойствием за дисковое пространство :)
В прошлой статье мы рассмотрели, как создавать в амазоне инстансы с помощью Terraform. В данной статье мы рассмотрим, как изменять то, что мы создали в облаке.
Из прошлой статьи у нас есть работающий сервер в амазоне, теперь нам необходимо изменить его параметры.
Допустим мы решили, что нам одного сервера недостаточно и нам понадобился еще один сервер. Мы можем внести изменение. Вместо count 1, подставим значение 2.
Сохраняем изменение в файле. Пробуем запустить, команду которая покажет, что у нас произойдет - terraform plan.
Мы видим, что в результате наших действий, будет добавлен еще один сервер. Запускаем на выполнение terraform apply. Не забываем, что необходимо подтвердить наше действие напечатав yes.
Мы можем увидеть, что в результате наших действий изменилось количество бегущих серверов. Теперь их 2 штуки.
Следующий шаг. Давайте попробуем изменить, размер сервера. У нас был t2.micro, возьмем немного побольше сервер t3.micro и уберем один лишний сервер изменив параметр count c 2 на 1.
Вводим команду terraform plan и видим, что один сервер будет уничтожен, а второй будет изменен.
Ну и стандартное уже terraform apply с подтверждением своих действий. Перейдем в консоль амазон и посмотрим, что происходит.
Амазон, в соответствии с произведёнными изменениями меняет размер виртуального сервера и уничтожает лишний. Теперь, можно посмотреть в официальной документации resource aws_instance, те параметры, которые можно изменять таким нехитрым образом в амазон с помощью Terraform.
Давайте добавим так, чтобы обозначить, например, сервер. На старице в официальной документации, было показано, что внутрь ресурса надо добавить.
tags = {
Name = "Vasya"
}
И отправляем изменения в амазон terraform apply. На выходе мы получим.
Сервер с именем Vasya. По факту мы не сделали ничего нового, просто изменили пустые параметры, грубо говоря просто подписали, добавили tags. Tags имеет смысл добавлять к каждому развертываемому серверу, потому что в крупных проектах, когда серверов более 100, а то и пол тысячи, будет очень легко запутаться и в параметрах и в запущенных серверах. В этом случае tag или по-другому метки, нас выручат очень хорошо.
Обратите внимание, когда мы вносим, какое-либо изменение в код, то при выводе результата команды terraform plan, на против планируемых изменений мы видим знак + зеленый если добавляется что-то или знак - красный если мы, что-то убираем.
Еще не мало важный фактор. Нельзя вносить изменения в сервера, в ручном режиме через консоль, которые мы обслуживаем с помощью Terraform. Все, изменения, которые вы внесете в ручном режиме, будут удалены при синхронизации, потому что данных параметров нет в коде.
Следовательно, исходя из этого принципа, удалять ресурсы тоже необходимо через код. Делается это достаточно просто, просто необходимо удалить ресурс из кода или поставить параметр count = 0 внутри ресурса.
В нашем примере я изменил параметр count = 0. И можно видеть, что Terraform сообщил нам о том, что сервер будет уничтожен в облаке.
И действительно, если мы посмотрим в консоль, то мы увидим, что все сервера в облаке находятся в состоянии terminated, в течении полутора минут.
Это означает, что данные сервера выключены и готовятся к удалению. Если у нас несколько серверов предназначен для удаления, то Terraform будет производить выключение и последующее удаление данных серверов параллельно.
Виртуализация серверов – это разделение одного физического сервера на несколько виртуальных серверов, каждый из которых работает под управлением собственной операционной системы. Эти операционные системы также известны, как «гостевые операционные системы». Они в свою очередь работают в другой операционной системе, которая также известна, как «хостовая операционная система». Каждый «гость», который работает таким образом, не знает о других «гостях», которые работают на том же хосте. Для того, чтобы обеспечить такую незаметность, используются различные методы виртуализации.
Разновидности виртуализации сервера:
Гипервизор
Гипервизор, или VMM (virtual machine monitor – монитор виртуальных машин), - это своего рода слой между операционной системой и оборудованием. Он обеспечивает работу необходимых служб и функций для того, чтобы несколько операционных систем могли работать без сбоев.
Он выявляет ловушки, отвечает на инструкции привилегированного процессора, организует очереди, выполняет диспетчеризацию и отвечает на аппаратные запросы. Операционная система хоста, которая управляет виртуальными машинами работает поверх гипервизора.
Паравиртуализация
Паравиртуализация основана на гипервизоре. В этой модели обрабатывается больше всего ресурсов, которые необходимы для эмуляции и организации программных ловушек в программно реализованной виртуализации. Гостевая операционная система перед установкой на виртуальную машину модифицируется и заново компилируется.
Производительность модифицированной гостевой операционной системы повышается, так как она взаимодействует напрямую с гипервизором, а потребление ресурсов эмуляцией сходит на нет.
Пример
: Xen в основном используют паравиртуализацию, где для поддержки административной среды, также известной как домен 0, используется настраиваемая среда Linux.
Преимущества:
Проще
Повышенная производительность
Нет дополнительного потребления ресурсов, связанного с эмуляцией
Недостатки:
Необходима модификация гостевой операционной системы
Полная виртуализация
Полная виртуализация очень похожа на паравиртуализацию. Она может эмулировать базовое аппаратное обеспечение, если это необходимо. Гипервизор перехватывает машинные операции, которые операционная система использует для выполнения операций ввода-вывода или изменения состояния системы. После того, как операции были перехвачены, они эмулируются в программном обеспечении, при этом коды состояния почти полностью можно сопоставить с теми, которые могли быть предоставлены реальным аппаратным обеспечением. Именно поэтому немодифицированная операционная система может работать поверх гипервизора.
Пример
: данный метод использует VMWare ESX. В качестве административной ОС используется настраиваемая версия Linux, также известная как Service Console. Этот метод не такой быстрый, как паравиртуализация.
Преимущества
:
Не требуется модификация гостевой операционной системы
Недостатки
:
Сложный метод
Более медленный из-за наличия эмуляции
Затрудняет установку нового драйвера устройства
Виртуализация с аппаратной поддержкой
Если говорить о принципе работы, то этот метод аналогичен полной виртуализации и паравиртуализации, за исключением того факта, что он требует аппаратной поддержки. Большая часть потребляемых гипервизором ресурсов при перехвате и эмуляции операций ввода-вывода и кодов состояния, которые выполняются в гостевой ОС, покрывается аппаратным расширением архитектуры х86.
Здесь можно запустить и немодифицированную ОС, так как для обработки запросов на доступ к оборудованию, привилегированных и защищенных операций, а также для связи с виртуальной машиной будет использоваться аппаратная поддержка виртуализации.
Пример
: аппаратную поддержку виртуализации обеспечивают такие технологии, как AMd – V Pacifica и Intel VT Vanderpool.
Преимущества
:
Не требуется модификация гостевой операционной системы
Гипервизор потребляет не так много ресурсов
Недостатки
:
Требуется аппаратная поддержка
Виртуализация на уровне ядра
Вместо того, чтобы использовать гипервизор, слой виртуализации запускает отдельную версию ядра Linux и рассматривает связанную с ней виртуальную машину как процесс из пользовательского пространства на физическом хосте. Это в какой-то степени упрощает запуск нескольких виртуальных машин на одном хосте. Для связи между основным ядром Linux и виртуальной машиной используется драйвер устройства.
Для виртуализации требуется аппаратная поддержка (Intel VT или AMD - V). В качестве контейнеров отображения и выполнения для виртуальных машин используется немного модифицированный процесс QEMU. Во многом виртуализация на уровне ядра – это специализированная форма виртуализации серверов.
Пример
: пользовательский режим Linux (UML - User – Mode Linux) и Kernel Virtual Machine (KVM).
Преимущества
:
Не требуется специальное программное обеспечение для администрирования
Низкое потребление ресурсов
Недостатки
:
Требуется аппаратная поддержка
Виртуализация на системном уровне или уровне ОС
Эта модель запускает несколько различных (с логической точки зрения) сред на одном экземпляре ядра операционной системы. Иначе его называют «подходом на основе общего ядра», так как все виртуальные машины используют одно общее ядро операционной системы хоста. Эта модель основана на концепции изменения корневого каталога «chroot».
сhroot начинает свою работу во время загрузки. Ядро использует корневые файловые системы для загрузки драйверов и выполнения других задач инициализации системы на ранних этапах. Затем оно переключается на другую корневую файловую систему с помощью команды chroot для того, чтобы организовать новую файловую систему на диске в качестве окончательной корневой файловой системы и продолжить инициализацию и настройку системы уже в этой файловой системе.
Механизм chroot виртуализации на системном уровне – это расширение этой концепции. Он позволяет системе запускать виртуальные серверы с их собственным набором процессов, которые выполняются относительно их собственных каталогов файловой системы.
Основное различие между виртуализацией на уровне системы и виртуализацией серверов состоит в том, что в одном случае можно запускать различные операционные системы в разных виртуальных системах, а в другом – нет. Если речь идет о виртуализации на системном уровне, то все виртуальные серверы должны использовать одну и ту же копию операционной системы, а если о виртуализации серверов, то здесь на разных серверах могут быть разные операционные системы (в том числе и разные версии одной операционной системы).
Пример
: FreeVPS, Linux Vserver, OpenVZ и другие.
Преимущества
:
Значительно проще, чем укомплектованные машины (включая ядро)
Можно разместить гораздо больше виртуальных серверов
Повышенная безопасность и улучшенная локализация
Виртуализация операционной системы практически не потребляет дополнительных ресурсов
Благодаря виртуализации операционной системы возможна динамическая миграция
Может использоваться динамическая балансировка нагрузки контейнеров между узлами и кластерами
При виртуализации операционной системы можно использовать метод копирования при записи (CoW - copy-on-write) на уровне файла. Он упрощает резервное копирование данных, экономит пространство и упрощает кэширование в сравнении с копированием при записи на уровне блока.
Недостатки
:
Возникшие проблемы с ядром или драйвером могут вывести из строя все виртуальные серверы