По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
За последние несколько лет, объем устройств хранения увеличился в несколько раз, и параллельно с ним увеличивается объем используемых данных. Появляются мощные инструменты, позволяющие наиболее эффективно использовать выделенное пространство. Одна из технологий, доступных в Windows Server - это дедупликация. Microsoft продолжает добавлять новые возможности к функции дедупликации с каждым новым выпуском Windows.
Рассмотрим само понятие дедупликации, инсталляцию компонентов и работу в Windows Server. Включение дедупликации на томе, использование Планировщика заданий, а также использование PowerShell для проверки статуса работы и управления.
Что такое дедупликация данных в Windows Server?
Файловый сервер предприятия – хороший пример, с помощью которого можно визуализировать, на сколько могут быть огромны объемы пользовательских данных. На файловом ресурсе можно найти множество копий одних и тех же файлов или близко схожих по внутренней структуре, т.е. в нескольких файлах будут дублироваться блоки данных. Одни и те же отчеты, письма, служебные документы пересылаются и сохраняются пользователями разных подразделений на одном и том же файловом сервере. А это, в свою очередь, приводит к появлению избыточных копий, которые влияют на эффективность хранения данных и последующего резервирования.
В традиционных средах хранения так и происходит. Дедупликация предоставляет средства для однократного сохранения данных и создания ссылок на фактическое расположение данных. Таким образом, среда хранения перестает хранить дублирующуюся информацию. Компания Microsoft также продолжает совершенствовать функции дедупликации. В Windows Server 2019 появилась возможность выполнять дедупликацию томов NTFS и ReFS. До Windows Server 2019 дедупликация ReFS была невозможна.
Как работает дедупликация данных Windows Server?
Для реализации дедупликации данных в Windows Server использует два принципа
Процесс дедупликации с данными выполняется не моментально. Это означает, что процесс дедупликации не будет влиять на производительность в процессе записи файла. Когда данные записываются в хранилище, они не оптимизируются. После этого запускается процесс оптимизации дедупликации, чтобы гарантировать дедупликацию данных.
Конечные пользователи не знают о процессе дедупликации - дедупликация в Windows Server полностью прозрачна. Пользователи не подозревают, что они могут работать с дедуплицированными данными.
Для успешной дедупликации данных в соответствии с принципами, перечисленными выше, Windows Server использует следующие шаги:
Файловая система сканирует хранилище, чтобы найти файлы, соответствующие политике оптимизации дедупликации.
Файлы дробятся на фрагменты.
Идентифицируются уникальные фрагменты данных
Фрагменты помещаются в хранилище фрагментов.
Создаются ссылки на хранилище фрагментов, чтобы было перенаправление при чтении этих файлов на соответствующие фрагменты.
Использование дедупликации
Ниже описана примерная экономия места при использовании дедупликации.
80–95% для сред виртуализации VDI, ISO файлы.
70–80% для файлов программного обеспечения, файлов CAB и других файлов.
50–60% для общих файловых ресурсов, которые могут содержать огромное количество дублированных данных.
30–50% для стандартных пользовательских файлов, которые могут включать фотографии, музыку и видео.
Установка компонентов дедупликации в Windows Server
Процесс установки Data Deduplication прост. Дедупликация данных является частью роли файловых служб и служб хранения. Можно установить используя графический интерфейс Server Manager, используя Windows Admin Center или командлет PowerShell.
Включить Дедупликацию из PowerShell можно следующим командлетом:
Install-WindowsFeature -Name FS-Data-Deduplication
Третий способ установить Дедупликацию данных – через Windows Admin Center перейдя в меню Roles & Features и установить галку напротив Data Deduplication. Затем нажать Install. Windows Admin Center предварительно должен быть установлен!
Включение дедупликации данных на томе
После того, как была установлена Дедупликация данных, процесс включения на томе будет простым. Используя Server Manager (Диспетчер серверов) перейдите к File and Storage Services (Файловым службам и службам хранения) -> Volumes (Тома) -> Disks (Диски). Выберите нужный диск. Затем выберите том, который находится на диске, на котором нужно запустить процесс дедупликации.
Выберем Configure Data Deduplication
На этом этапе можно выбрать тип данных для дедупликации: файловый сервер, VDI или Backup Server, в Параметрах установить возраст файлов для дедупликации, возможность добавить файлы или папки для исключения.
Здесь же настраивается расписание
В конфигурации расписания можно добавить дополнительное задание на то время, когда сервер используется минимально, чтобы максимально использовать возможности дедупликации.
Выполнение запланированных задач дедупликации данных
После создания расписания, в Task Scheduler (Планировщик заданий) создается новая задача, работающая в фоновом режиме. По умолчанию процесс дедупликации стартует каждый час. Запустив Task Scheduler и перейдя по пути MicrosoftWindowsDeduplication можно запустить задачу BackgroundOptimization вручную.
Использование PowerShell для проверки работы и управления дедупликацией
В PowerShell имеются командлеты для мониторинга и управления дедупликацией
Get-DedupSchedule – покажет расписание заданий
Можно создать отдельное дополнительное задание по оптимизации дедупликации на томе E: с максимальным использованием ОЗУ 20%
Start-DedupJob -Volume "E:" -Type Optimization -Memory 20
Get-DedupStatus – отобразит состояние операций дедупликации и процент дедупликации
На данном этапе нет экономии места после включения дедупликации данных. В настройках расписания указано дедуплицировать файлы старше 2-х дней.
После запуска процесса мы начинаем видеть экономию места на томе.
Get-DedupMetadata - просмотр метаданных по дедупликации
Server Manager также отобразит измененную информацию.
Если нужно отключить использование дедупликации, нужно использовать два командлета:
Disable-DedupVolume -Volume
Start-DedupJob -type Unoptimization -Volume
Необходимо учесть, что обратный процесс уменьшит свободное пространство на томе и у вас должно быть достаточно для этого места.
Вывод
Дедупликация данных в Windows Server - отличный способ эффективно использовать место на устройствах хранения данных. С каждым выпуском Windows Server возможности дедупликации продолжают улучшаться. Дедупликация обеспечивает огромную экономию места, особенно для файловых серверов и сред виртуализации VDI. Для последних экономия места может достигать 80 и более %.
Использование дополнительных опций, таких как расписание, управление типами файлов и возможность использовать исключения позволяет гибко настраивать дедупликацию. PowerShell предоставляет несколько командлетов, которые позволяют взаимодействовать, управлять и контролировать дедупликацию данных в Windows Server.
Ищешь бесплатное решение по реализации исходящих звонков из CRM Битрикс24 в связке с Asterisk? Поздравляем, нашел. Можешь закрыть все остальные вкладки и оставить только эту – пошаговое руководство по интеграции Б24 и Астериска в статье :)
Как это работает?
Легко (на этом можно было бы закончить). Мы создаем исходящий вебхук в Битрикс, он дергает php - скрипт на Asterisk каждый раз, когда мы будем нажимать на номер телефона в лиде, сделке, контакте – где угодно. Поехали.
Попробовать Битрикс24
Подготовка
Создадим AMI (Asterisk Manager Interface)– юзера, через которого будем инициировать вызовы. Откроем файл настройки:
vim /etc/asterisk/manager.conf
Обращаем внимание на секцию [general] - параметр enabled должен быть в значении yes:
[general]
enabled = yes // вот этот параметр :)
port = 5038
bindaddr = 0.0.0.0
Проверьте, чтобы в самом конце файла manager.conf были следующие строки (если их нет, добавьте):
#include manager_custom.conf
Проверили. А теперь открываем файл /etc/asterisk/manager_custom.conf (если его нет – создайте и дайте права) и добавляем туда:
[имя]
secret = пароль
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
permit=ip_адрес_Asterisk/маска
read = all,system,call,log,verbose,command,agent,user,config,originate
write = all,system,call,log,verbose,command,agent,user,config,originate
имя - придумайте имя для юзера;
пароль - создайте устойчивый к взломам пароль, с помощью сервисов онлайн генерации, например;
ip_адрес_Asterisk/маска - укажите вашу подсеть. В указанной подсети должен находится IP – адрес, с которого скрипт будет обращаться к AMI. Пример записи - 192.168.1.0/255.255.255.0;
Переходим в Битрикс24 и создаем вебхуки.
Вебхуки
Первый вебхук мы сделаем входящим – по нему наш скрипт будет получать внутренний номер сотрудника по его идентификатору. Переходим в раздел Приложения → Вебхуки. Нажимаем кнопку Добавить вебхук и выбираем Входящий вебхук. Делаем вот что:
Название - любое название, как вам удобно;
Описание - нужный момент, чтобы не запутаться в вебхуках;
Права доступа - отметьте галочкой Пользователи (user);
Нажимаем сохранить. Должно получиться примерно вот так:
Обратите внимание: на скриншоте, красной линией подчеркнут URL параметра Пример URL для вызова REST. Скопируйте его ровно до последней части /profile/. Например, у нас получилось:
https://merionet.bitrix24.ru/rest/2/1a2b3c4d5e6f7g8h
Сохраните этот URL – он нам еще пригодится :) Перед тем, как мы сделаем исходящий вебхук, давайте обсудим будущий URL нашего скрипта. Так как он будет располагаться в веб директории, мы предлагаем вам сгенерировать последовательно 3 директории, в которых будет лежать скрипт. И вот о чем мы: представим, что ваш домен выглядит вот так:
http://ilovemerionet.ru/
Гуд. Давайте последовательно сгенерируем 3 уникальных названия директорий, например:
IpVy7ul85sz1Doi
C49BNGJW3Yf30eo
qBN0NBC56lj07yh
После чего, в директории /var/www/html/ создадим три вложенных папки, чтобы наш файл в конечно итоге размещался в директории:
/var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/
Сам файл скрипта, который мы сгенерируем, будет называться index.php, тем самым, вебхук со стороны Битрикс24 будет обращаться по следующему URL:
http://ilovemerionet.ru/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/
Кажется, разобрались :) Теперь создаем исходящий вебхук – прыгаем в раздел Приложения → Вебхуки. Нажимаем кнопку Добавить вебхук и выбираем Исходящий вебхук. Делаем вот что:
Код авторизации - это наш проверочный код, который мы используем в скрипте;
Адрес обработчика - как мы привели пример выше, тут будет http://ilovemerionet.ru/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/ - у вас, само собой, свой URL :);
Название - явное название, чтобы не запутаться. Сделайте Asterisk Calls, например?;
Комментарий - можете оставить комментарий для себя, чтобы было проще разобраться;
Тип события - выбираем Инициация звонка через приложение (ONEXTERNALCALLSTART);
Великолепно. Мы выходим на финишную прямую.
Скрипт для Asterisk
Ловите скрипт, который будет принимать вебхуки от Битрикс24. Комментарии к самым важным строкам, как всегда, присутствуют:
<?php
$check_token = "Код_авторизации"; // это значение будет прилетать нам в вебхуке. А мы будем его сравнивать, чтобы быть уверенными, что это Битрикс;
$user_hook_url = "Часть_входящего_вебхука"; // нужно, для получения внутреннего номера пользователя, которые инициирует звонок;
$ami_login = "ami_логин"; // логин к AMI, который мы создавали ранее;
$ami_password = "пароль"; // пароль к AMI, который мы создавали ранее;
$strhost = "IP_адрес"; // IP - адрес вашего Asterisk;
if (strcmp($_POST['auth']['application_token'], $check_token) === 0) {
function writeToLog($data, $title = '') {
$log = "
------------------------
";
$log .= date("Y.m.d G:i:s") . "
";
$log .= (strlen($title) > 0 ?
$title : 'DEBUG') . "
";
$log .= print_r($data, 1);
$log .= "
------------------------
";
file_put_contents(getcwd() . '/hook.log', $log, FILE_APPEND);
return true; }
writeToLog($_REQUEST, 'incoming');
$UID = $_POST['data']['USER_ID'];
$bitrix_contact_url = "$user_hook_url/user.get.json?ID=$UID";
$btc = curl_init();
curl_setopt ($btc, CURLOPT_URL,$bitrix_contact_url);
curl_setopt ($btc, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($btc, CURLOPT_TIMEOUT, 60);
curl_setopt ($btc, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($btc, CURLOPT_RETURNTRANSFER, 1);
$bitrix_contact = curl_exec ($btc);
curl_close($btc);
$bitrix_contact_o = json_decode($bitrix_contact, true);
$cid = $bitrix_contact_o['result'][0]['UF_PHONE_INNER'];
$strport = "5038";
$timeout = "5";
$num = str_replace("+","",$_POST['data']['PHONE_NUMBER_INTERNATIONAL']);
$callid = $_POST['data']['CALL_ID'];
$c="from-internal";
$p="1";
$errno=0 ;
$errstr=0 ;
$sconn = fsockopen($strhost, $strport, &$errno, &$errstr, $timeout) or die("Connection to $strhost:$strport failed");
if (!$sconn) { echo "$errstr ($errno)
"; }
else {
$sconn1 = fsockopen($strhost, $strport, &$errno, &$errstr, $timeout) or die("Connection to $strhost:$strport failed");
if (!$sconn1) { echo "$errstr ($errno)
"; }
else {
fputs($sconn1, "Action: login
");
fputs($sconn1, "Username: $ami_login
");
fputs($sconn1, "Secret: $ami_password
");
fputs($sconn1, "Events: off
");
usleep(500);
fputs($sconn1, "Action: Setvar
");
fputs($sconn1, "Variable: B24ID
");
fputs($sconn1, "Value: $callid/$cid
");
fputs($sconn1, "Action: Logoff
");
usleep(500);
$wrets1=fgets($sconn1,128);
fclose($sconn1);}
fputs($sconn, "Action: login
");
fputs($sconn, "Username: $ami_login
");
fputs($sconn, "Secret: $ami_password
");
fputs($sconn, "Events: off
");
usleep(500);
fputs($sconn, "Action: Originate
");
fputs($sconn, "Channel: SIP/$cid
");
fputs($sconn, "Callerid: $cid
");
fputs($sconn, "Timeout: 20000
");
fputs($sconn, "Context: $c
");
fputs($sconn, "Exten: $num
");
fputs($sconn, "Priority: $p
");
fputs($sconn, "Async: yes
" );
usleep(500);
$wrets=fgets($sconn,128);
fclose($sconn);
exit;
}} else {
exit;
};
?>
Скачать скрипт интеграции
После загрузки файла, сохраните его с расширением .php
В нем вам нужно поменять 5 переменных:
$check_token - код авторизации, который вы получили на этапе создания исходящего вебхука;
$user_hook_url - та часть входящего вебхука, которая подчеркнута на скриншоте до слов /profile/;
$ami_login - логин в AMI, создавали ранее;
$ami_password - пароль в AMI;
$strhost - IP - адрес вашего Asterisk;
Чтобы скрипт заработал, нужно, как мы говорили ранее, загрузить его в директорию /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/ (после генерации директорий у вас будет свой путь!) и дать следующие команды:
dos2unix /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/index.php
chown asterisk:asterisk /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/index.php
chmod 775 /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/index.php
Кстати, профит этого скрипта в том, что он ведет логирование в файле hook.log, который будет располагаться в той же директории. Если кто – то из ваших менеджеров скажет, что не смог позвонить клиенту – это будет легко проверить :)
Почти готово. Остался только один штрих. Снова открываем CRM Битрикс24, переходим в сегмент Телефония → Настройки и в параметре Настройка номеров по-умолчанию выбираем созданный нами вебхук (у нас он называется Приложения: Asterisk Calls:
А вот теперь готово. Звоним
Звонит :) Но! Не закрывает карточку и не добавляет отметку об исходящем звонке в сущность CRM (запись разговора). Внимательные пользователи обратят внимание – в AMI сегменте скрипта, который обсуждали ранее, мы кинули команду Setvar (присвоение переменной) к B24ID = $callid. Тем самым, на всем протяжении звонка у нас будет идентификатор этой телефонной транзакции.
Фактически, чтобы получить отметку о звонке, запись разговора и прочее, по факту окончания разговора нужно методом telephony.externalcall.finish кинуть массив данных, где будет отметка об идентификаторе вызова (которую передаем через диалплан), телефон инициатора вызова, длительность и ссылка на запись разговора.
Если данная статья вызовет интерес, мы покажем, как это сделать. Удачи с настройкой :)
Семантическое управление версиями (или семвер) – это формальное соглашение для определения номера версии новых выпусков программного обеспечения. Стандарт помогает пользователям программного обеспечения понять серьезность изменений в каждом новом дистрибутиве.
Проект, использующий семантическое управление версиями, объявляет основной номер версии (major), дополнительный номер версии (minor) и номер исправления (patch) для каждого выпуска. Строка версии 1.2.3 указывает на основную версию под номером 1, дополнительную версию под номером 2 и исправление под номером 3.
Номера версий такого формата широко используются как программными пакетами, так и исполняемыми файлами конечных пользователей, такими как приложения и игры. Однако не каждый проект точно следует стандарту, установленному semver.org.
Спецификация была создана для решения проблем, вызванных несовместимостью методов управления версиями между программными пакетами, используемыми в качестве зависимостей. Под «пакетом» и «зависимостью» мы подразумеваем библиотеку кода, предназначенную для использования в другом программном проекте и распространяемую диспетчером пакетов, таким как npm, composer или nuget. Это именно то применение семантического управления версиями, которое мы рассматриваем в этой статье.
Major, Minor и Patch
Важно понимать значение трех задействованных компонентов. Вместе они намечают путь разработки проекта и соотносят влияние каждого нового выпуска на конечных пользователей.
Major number (основной номер версии) – основной номер указывает на текущую версию общедоступного интерфейса пакета. Он увеличивается каждый раз, когда вы вносите изменения, которые требуют от существующих пользователей вашего пакета обновления их собственной работы.
Minor number (дополнительный номер версии) – дополнительный номер указывает на текущую функциональную версию вашего программного обеспечения. Он увеличивается всякий раз, когда вы добавляете новую функцию, но не меняете интерфейс вашего пакета. Он сообщает пользователям о том, что были внесены значительные изменения, но пакет полностью совместимым с предыдущими версиями с предыдущим дополнительным номером.
Patch number (номер исправления) – номер исправления увеличивается каждый раз, когда вы вносите какое-то незначительное изменение, которое не влияет на общедоступный интерфейс или общую функциональность вашего пакета. Его чаще всего используют для исправления ошибок. Потребители всегда должны иметь возможность не задумываясь установить последнюю версию исправлений.
Семантическая структура версии выпуска лучше всего моделируется в виде дерева. Наверху у вас изменения общедоступного интерфейса, каждое из которых отображается на основном номере. Каждая основная версия имеет свой собственный набор дополнительных версий, в которые добавляются новые функции без нарушения совместимости с предыдущими версиями. И наконец, дополнительные версии могут время от времени отлаживаться путем исправления некоторых ошибок.
Откуда начинать?
Большинство проектов должны начинаться с версии 1.0.0. Вы публикуете свой первый общедоступный интерфейс и первоначальный неизмененный набор функций. И поскольку вам еще не приходилось вносить никаких исправления, то и версия исправления – 0.
Теперь давайте посмотрим, что же происходит, когда вы вносите изменения в свой пакет. После вашего первоначального выпуска вы получаете отчет об ошибке от пользователя. Когда вы выпустите исправление, то правильный номер версии уже будет 1.0.1. Если бы вы затем выпустили еще одну версию с исправлением ошибок, то вы бы увеличили номер исправления до 2, т.е. номер версии уже был бы 1.0.2.
Тем временем вы также работали над новой интересной функцией. Это совершенно необязательно, поэтому пользователям не нужно ничего делать для обновления. Вы выпускаете эту версию как 1.1.0. – создана новая функциональная среда, но ее еще ни разу не исправляли. К сожалению, скоро приходят отчеты об ошибках, и среди ваших пользователей начинает распространяться версия 1.1.1.
Несколько месяцев спустя вы решили провести реорганизацию кода всего проекта. Некоторые функции были удалены или теперь доступны через объединенный интерфейс. Если вы выпустите эту работу, то люди, использующие текущую версию вашего пакета, должны будут внести серьезные изменения в свой проект. Пришло время опубликовать 2.0.0. в вашем репозитории пакетов.
Поддержание старых веток
Увеличение какого-либо номера в вашей строке версий не создает точку невозврата. После публикации 1.1.1 вы могли обнаружить ошибку, присутствующую в 1.0.2. Используя ветки в вашей системе контроля версий, вы можете произвести исправления в обеих версиях. В итоге вы получите 1.1.2 и 1.0.3.
Точно также вы можете поддерживать ветку 1.х вашего проекта, несмотря на выпуск 2.0.0. Может показаться странным публиковать 1.1.2 после 2.0.1, но это вполне нормальная практика. Семантическое управление версиями не создает линейный постоянно увеличивающийся номер версии; наоборот, оно предназначено для использования в качестве части модели разработки ветвления, которое использует простоту установки исправлений, предлагаемую системами управления исходным кодом, такими как Git.
Опубликованные версии должны быть неизменяемыми. После того, как вы создали версию 2.4.3, вы не можете «обновить» его, просто добавив дополнительный код в ту же строку версии. Вы должны присваивать новый номер версии каждому выпуску, чтобы пользователи всегда могли получить доступ к каждой конкретной версии вашего пакета.
Обработка пакетов, находящихся в стадии разработки
Как правило, вы всегда обновляете основную версию своего пакета всякий раз, когда вносятся изменения, несовместимые с предыдущими версиями. Когда вы находитесь в стадии разработки, то ваша кодовая база может дорабатываться очень быстро, что приводит к публикации множества основных версий.
Вы можете этого избежать, рекламируя свой проект как 0.y.z. Значение 0 в качестве основной версии означает, что ваш пакет неустойчив. Обычные правила в отношении совместимости с предыдущими версиями тут не применяются, поэтому вы можете выпускать новые версии, увеличивая только дополнительный номер и номер исправления. Это значит, что вы можете использовать 1.0.0 для обозначения первой «завершенной» версии вашего программного обеспечения.
Вы также можете добавить дополнительные «идентификаторы» в конец строки версии, используя дефис в качестве разделителя: 1.0.0-alpha.1. Вы можете использовать такой вариант для того, чтобы четко обозначить альфа- и бета-версии. Точно также вы можете включить метаданные сборки, добавив символ +: 1.1.0-alpha.1+linux_x86.
Заключение
Согласованное использование семантического управления версиями помогает пользователям быть уверенными в вашем проекте. Они могут четко видеть, как развивается ваша кодовая база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.
Объявление строки семантической версии необходимо при публикации в диспетчере наиболее популярных пакетов. Тем не менее, в конечном счете, вам решать, какие номера вы устанавливаете для каждого нового выпуска. Соблюдение стандарта четко сообщает о ваших намерениях пользователям и сводит к минимуму риск непреднамеренного нарушения чужой работы.