По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня мы расскажем вам, как настроить программный RAID 0 в Windows Server 2016 Core. В интернете полно информации о настройке чередующегося тома (а именно так именуется RAID0) через графический интерфейс. Мы этим заниматься не будем. Мы создадим чередующийся том через консоль.
Для примера возьмем, установленную на Hyper-V виртуальную машину Windows Server 2016 Core.
Предварительно нам необходимо создать два новых жестких диска, которые мы будем переводить в Raid0.
Не включаем виртуальную машину. Нажимаем правой кнопкой мыши на нашей машине. В раскрывшемся меню выбираем пункт Параметры:
В открывшемся окне кликаем по пункту Установка оборудования и выбираем пункт SCSi-контроллер.
Нажимаем Добавить и в следующем окне выбираем пункт Жесткий диск и нажимаем Добавить
В следующем окне из раскрывающегося списка Расположение выбираем номер, который не используется другими устройствами.
После этого, под пунктом Виртуальный жесткий диск нажимаем кнопку Создать
Откроется окно Приступая к работе. Здесь просто приветственное окно и нажимаем Далее.
В окне Выбор формата диска устанавливаете переключатель на нужный вам формат диска. Мы выбрали формат VHDX. Нажимаем Далее.
В окне Выбор типа диска устанавливаете переключатель в необходимый тип диска. На выбор три типа: Фиксированного размера, Динамически расширяемый, Разностный.
И опять нажимаем кнопку Далее и перед нами откроется окно выбора имени диска и его местоположения. Задайте диску имя и укажите место, где он будет располагаться.
Нажимаем Далее. Откроется окно Настройки диска. Здесь необходимо задать объем жесткого диска. Мы установили 40 Gb. Нажимаем кнопку Далее.
Откроется окно Завершение настройки виртуального жесткого диска. Нажимаем Готово и в последнем окне нажимаем ОК.
Аналогичным образом создается второй виртуальный жесткий диск. После того, как создали два диска, включаем нашу виртуальную машину. Входим под учетной записью Администратор’а.Вводим команду Diskpart:
Выбираем Диск 1 командой select disk 1:
Переводим его в режим online: Вводим команду online disk:
Делаем диск динамическим командой convert dynamic:
Может появиться ошибка, что диск защищен от записи. Эта проблема решается вводом команды
Attribute disk clear readonly
И повторно пытаемся сделать диск динамическим. Просматриваем заново наши диски командой list disk
Звездочки напротив диска означают, что диск динамический.
Аналогичные операции проводим и для диска 2. Все команды для диска 2 отображены на рисунке ниже.
Далее, не меняя диск, вводим команду: create volume stripe disk=1,2. Данная команда создает чередующийся том.
Для просмотра результатов выполнения команды вводим команду list volume.
Из рисунка выше видно, что создан новый том (ТОМ3), который является Raid 0 (ЧЕРЕДУЮЩИЙСЯ).
Теперь нам осталось присвоить литеру нашему новому тому.
Для этого вводим команду assign letter=Y и проверяем командой list volume.
Теперь нам надо отформатировать новый том, что бы можно было его использовать для сохранения информации.
Выходим из режима Diskpart командой exit
Для форматирования диска вводим команду следующего типа: format Y: /q /FS:NTFS. После чего система запросит подтверждения выполняемого действия и предупредит, что все данные будут уничтожены. Вводим yes. Начнется процесс форматирования.
P.S. Иногда возникает необходимость установить букву диска, которая уже присвоена другому, например приводу DVD дисков. Для изменения литеры необходимо выполнить ряд команд:
Зайти в diskpart;
Просмотреть тома командой list volume;
Выделить нужный том, на котором необходимо сменить букву- select volume 0;
Удалить присвоенную букву командой remove letter=Y;
Присвоить новую букву- assign letter=V;
Привет, дорогой читатель! На этапе траблшутинга системные администраторы прибегают к просмотру и анализу лог – файлов Asterisk. В статье поговорим про причины отбоя вызова (hangupcause) в Asterisk, как их найти в лог – файле и что они означают.
Поиск Hangupcause
Подключаемся к нашему серверу IP – АТС по SSH. Открываем консоль и вводим следующую команду:
[root@asterisk ~]# grep -e '[CALLID].*HANGUPCAUSE' /var/log/asterisk/full
Здесь CALLID - это идентификатор вызова. Найти его очень просто. В лог – файле введите номер звонящего/вызываемого абонента и найдете примерно вот такую запись (в примере поиск осуществляется по номеру 89123456789):
[2017-02-08 18:58:03] VERBOSE[18823][C-00000009] pbx.c: Executing [recordcheck@sub-record-check:11] Goto("Local/89123456789@from-internal-00000007;2", "startrec") in new stack
Находим запись выше. Здесь, [C-00000009] - является идентификатором вызова.
После того, как Вы нашли hangupcause, его необходимо понять. Переходим к следующему шагу – интерпретация.
Все причины отбоя вызова в Asterisk
Ниже, в таблице, мы составили причины отбоя вызова и соответствующие для них коды SIP ответов с небольшим описанием:
Код отбоя (hangupcause)
Полученный SIP - ответ
Описание
1
410
Unallocated (unassigned) - неназначенный номер. Данная ошибка указывает, что вызываемый номер назначения не может быть вызван, по причине отсутствия маршрута до него. Как правило, данную ошибку возвращает провайдер телефонных услуг. Например, при звонка зарубеж, данная ошибка может возвращаться из-за отсутствия маршрута к номеру назначения.
2
500
No route to specified transit network - ошибка индицирует о том, что оборудование, сгенерировавшее данную ошибку получило запрос запрос на маршрутизацию вызова через неизвестную ей транзитную сеть. Вполне возможно, что данная сеть в целом не существует.
3
404
No route to destination - чисто "сетевая" ошибка. Обозначает отсутствие коннективити (маршрутизации) между сетями инициатора вызова и вызываемого абонента.
4
500
Send special information tone - вызываемый абонент не может быть вызван по причинам "долгосрочного характера", и звонящий должен получить специальный звуковой тон.
5
500
Misdialled trunk prefix - сигнализирует о том, что к вызываемому номеру был подставлен ошибочный телефонный префикс.
6
500
Channel unacceptable - проблемы на канале связи. Как правило это сетевая проблема.
7
500
Call awarded and being delivered in an established channel - индикация того, что пользователь получил входящий вызов и что пользователь уже имеет аналогичный вызов
8
500
Prefix 0 dialed but not allowed - префикс в начале номер "0" не разрешен
9
500
Prefix 1 dialed but not allowed - префикс в начале номер "1" не разрешен
10
—
Prefix 1 not dialed but required - префикс "1" подставлен в начало номера, но не является требованием
11
—
More digits received than allowed, call is proceeding - в вызываемом номере передано больше цифр, чем позволено на оборудовании передающим данный код отбоя
16
BYE
Normal call clearing - вызов был закончен естественным образом (кто - то из абонентов положил трубку)
17
486
User busy - индицирует, что вызываемый абонент не может принять вызов, так как находится в состоянии "Занят" (есть активный разговор)
18
480
No user responding - вызываемый абонент не ответил на сообщение о вызове (инициации) в течение определенного времени
19
480
T.301 expired: – User Alerted, No answer from user - аппарат вызываемого абонента звонил, но он не ответил на звонок
21
603
Call rejected - вызов отклонен
22
480
Number changed to number in diagnostic field - индицирует о том, что вызываемый номер более не существует. В сообщение так же может быть включен новый номер вызываемого абонента
23
—
Reverse charging rejected - вариант, когда за звонок платит принимающая вызов сторона. Данное сообщение обозначает отклонение такого вызова.
24
—
Call suspended - оборудование получило запрос на приостановку вызова
25
—
Call resumed - вызов возобновлен (продолжение 24 отбоя)
26
500
Non-selected user clearing - пользователю не был назначен входящий вызов
27
404
Destination out of order - данное сообщение индицирует о том, что телефонная сигнализация не может быть доставлена через выбранный NIC (сетевой интерфейс). В данном случае, проблема скорее всего кроется на L1 или на L2 уровне (физический или канальный)
28
484
Invalid number format or incomplete address - неправильный формат вызываемого номера или номер указан не полностью
29
501
EKTS facility rejected by network - проблема на уровне платы - устройство отклонено на уровне сети
30
500
Response to STATUS ENQUIRY - сообщение ответ на запрос о состоянии
31
404
Normal, unspecified - эта причина отбоя используется в случае, если другие причины (более конкретные) не были применены
33
—
Circuit out of order - построенный канал связи вышел из строя
34
503
No circuit/channel available - нет доступного для установления соединения канала связи
35
500
Destination unattainable - нет возможности доставить сообщение до получателя
36
500
Out of order - объект функционирует не корректно
37
500
Degraded service - уведомление о том, что сервис находится в некорректном состоянии
38
503
Network out of order - сетевое соединение функционирует не корректно (вероятная проблема на уровне L3)
39
500
Transit delay range cannot be achieved - требуемый диапазон задержки (время обработки, передачи) не может быть достигнут
40
500
Throughput range cannot be achieved - требуемый диапазон пропускной способности (передача сообщения) не может быть достигнута
41
503
Temporary failure - временная неработоспособность сервиса. "Временная" означает то, что пользователь может попробовать еще раз через некоторое время
42
503
Switching equipment congestion - в настоящее время, оборудование коммутации испытывает пиковые значения нагрузки и не может обработать запрос
43
500
Access information discarded - данная причина индицирует о том, что по запросу сеть (L3) не может доставить информацию о доступе к удаленному пользователю
44
503
Requested circuit channel not available - запрошенный канал связи недоступен
45
500
Preempted - данная причина указывает на то, что вызов был прерван
46
500
Precedence call blocked - означает, что вызываемый пользователь занят вызовов с более высоким приоритетом
47
503
Resource unavailable, unspecified - причина, отправляемая в том случае, если ни одна другая не была отправлена
49
500
Quality of service unavailable - использование QoS требование не доступно
50
500
Requested facility not subscribed - пользователь запросил услугу, которую он не может получить по причине отсутствия доступа к ней
51
—
Reverse charging not allowed - вариант, когда за звонок платит принимающая вызов сторона не разрешен для данного пользователя
52
—
Outgoing calls barred - исходящий вызов запрещен для абонента
53
500
Outgoing calls barred within CUG - данная причина означает, что несмотря то, что пользователь является членом закрытой группы юзеров (CUG - Closed User Groups) для совершения исходящего вызова, ему данная итерация запрещена
54
—
Incoming calls barred - входящий вызов запрещен для абонента
55
603
Incoming calls barred within CUG - данная причина означает, что несмотря то, что пользователь является членом закрытой группы юзеров (CUG - Closed User Groups) для приема входящего вызова, ему данная итерация запрещена
56
—
Call waiting not subscribed - пользователь не имеет права (не подписан) на услугу "Ожидание вызова"
57
501
Bearer capability not authorized - пользователь запросил расширение пропускной способности канала до оборудования, но не имеет права на подобные итерации
58
501
Bearer capability not presently available - пользователь запросил расширение пропускной способности канала до оборудования, но в данный момент данная функция не доступна
63
503
Service or option not available, unspecified - сообщение сообщает о недоступности услуги в том случае, если другие причины (более конкретные) не были отправлены пользователю
65
501
Bearer service not implemented - служба передачи (переноса) информации не реализована
66
500
Channel type not implemented - устройство, посылающее данную причину не поддерживает указанный типа канала связи
67
—
Transit network selection not implemented - не удалось совершить выбор транзитной сети
68
—
Message not implemented - данное сообщение не реализовано
69
500
Requested facility not implemented - эта причина указывает на то, что устройство, отсылающее эту причину не поддерживает запрашиваемые дополнительные услуги
70
500
Only restricted digital information bearer capability is available - данное сообщение указывает на то, что пользователь запросил неограниченный доступ к пропускной способности канала связи, но устройство поддерживает только с ограничениями
79
501
Service or option not implemented, unspecified - услуга или опция не реализована (когда другие причины не были отправлены)
81
500
Invalid call reference value - эта причина указывает на то, что устройство, отсылающее эту причину, получило сообщение с идентификатором вызова, который в настоящее время не используется на интерфейсе сети пользователя
82
500
Identified channel does not exist - эта причина указывает на то, что устройство, отсылающее эту причину, получило запрос на использование канала, который не активизирован на сетевом интерфейсе. Например, если пользователь использует в потоке Е1 (PRI) тайм – слоты с 1 по 12, а запросил использовать с 3 по 24 – будет сгенерирована данная причина
83
500
A suspended call exists, but this call identity does not - вызов существует, но отсутствуют идентификаторы для него
84
500
Call identity in use - оборудование получило запрос на приостановление вызова, содержащий идентификатор вызова, под которым вызов уже значится приостановленным
85
500
No call suspended - получен запрос на возобновление вызова с идентификатором звонка, который не числится в списке приостановленных
86
500
Call having the requested call identity has been cleared - получен запрос на возобновление вызова с идентификатором звонка, который был прерван в результате тайм - аута
87
603
Called user not member of CUG - вызываемый абонент не является членом закрытой группы юзеров (CUG - Closed User Groups)
88
404
Incompatible destination - система получила запрос на установление соединения с параметрами, которые не могут быть обслужены
89
—
Non-existent abbreviated address entry - не существующий адрес
90
500
Destination address missing, and direct call not subscribed - адрес назначения не указан, а опция директивного вызова недоступна для пользователя
91
500
Invalid transit network selection (national use) - получен индикатор транзитной сети, который имеет неверный формат (в рамках рекомендации Q.931)
92
—
Invalid facility parameter 93 Mandatory information element is missing - обязательный элемент информационного сообщения отсутствует
93
500
Message type non-existent or not implemented - получено устройством сообщение не может быть интерпретировано на оборудовании
95
404
Invalid message, unspecified - неправильное сообщение. Используется только тогда, когда другие (более конкретные сообщения) не были отправлены
96
500
Mandatory information element is missing - в полученном оборудованием сообщение отсутствует важное для его обработки поле
97
500
Message type non-existent or not implemented - тоже самое что и 93 код
98
500
Message not compatible with call state or message type non-existent or not implemented - сообщение не совместимо с текущим состоянием звонка или не может быть интерпретировано оборудованием
99
500
Information element nonexistent or not implemented - информационный элемент не существует или не может быть интерпретирован оборудованием
100
500
Invalid information element contents - элемент не может быть интерпретирован. Помимо этого, одно или более полей сообщения были закодировано алгоритмом, который не поддерживает оборудованием.
101
500
Message not compatible with call state - полученное сообщение не соответствует состоянию вызова
102
408
Recovery on timer expiry - процедура восстановления по причине тайм - аута параллельно с алгоритмами обработки ошибок
103
500
Parameter non-existent or not implemented – passed on - параметр не существует или не реализован на оборудовании
111
404
Protocol error, unspecified - ошибка, которая отправляется в случае, если более детальное сообщение не было отправлено
127
500
Internetworking, unspecified - на этапе установления соединения произошел сбой
Буферизация пакетов для работы с перегруженным интерфейсом кажется прекрасной идеей. Действительно, буферы необходимы для обработки трафика, поступающего слишком быстро или несоответствия скорости интерфейса - например, при переходе от высокоскоростной LAN к низкоскоростной WAN. До сих пор это обсуждение QoS было сосредоточено на классификации, приоритизации и последующей пересылке пакетов, помещенных в очередь в этих буферах, в соответствии с политикой. Максимально большой размер буферов кажется хорошей идеей. Теоретически, если размер буфера достаточно велик, чтобы поставить в очередь пакеты, превышающие размер канала, все пакеты в конечном итоге будут доставлены. Однако, как большие, так и переполненные буферы создают проблемы, требующие решения.
Когда пакеты находятся в буфере, они задерживаются. Некоторое количество микросекунд или даже миллисекунд добавляется к пути пакета между источником и местом назначения, пока они находятся в буфере, ожидая доставки. Задержка перемещения является проблемой для некоторых сетевых разговоров, поскольку алгоритмы, используемые TCP, предполагают предсказуемую и в идеале небольшую задержку между отправителем и получателем.
В разделе активного управления очередью вы найдете различные методы управления содержимым очереди. Некоторые методы решают проблему переполненной очереди, отбрасывая достаточно пакетов, чтобы оставить немного места для вновь поступающих. Другие методы решают проблему задержки, поддерживая небольшую очередь, минимизируя время, которое пакет проводит в буфере. Это сохраняет разумную задержку буферизации, позволяя TCP регулировать скорость трафика до скорости, соответствующей перегруженному интерфейсу.
Управление переполненным буфером: взвешенное произвольное раннее обнаружение (WRED)
Произвольное раннее обнаружение (RED) помогает нам справиться с проблемой переполненной очереди. Буферы не бесконечны по размеру: каждому из них выделено определенное количество памяти. Когда буфер заполняется пакетами, новые поступления отбрасываются. Это не сулит ничего хорошего для критического трафика, такого как VoIP, от которого нельзя отказаться, не повлияв на взаимодействие с пользователем. Способ решения этой проблемы - убедиться, что буфер никогда не будет полностью заполнен. Если буфер никогда не заполняется полностью, то всегда есть место для приема дополнительного трафика.
Чтобы предотвратить переполнение буфера, RED использует схему упреждающего отбрасывания выбранного входящего трафика, оставляя места открытыми. Чем больше заполняется буфер, тем больше вероятность того, что входящий пакет будет отброшен. RED является предшественником современных вариантов, таких как взвешенное произвольное раннее обнаружение (WRED). WRED учитывает приоритет входящего трафика на основе своей отметки. Трафик с более высоким приоритетом будет потерян с меньшей вероятностью. Более вероятно, что трафик с более низким приоритетом будет отброшен. Если трафик использует какую-либо форму оконного транспорта, например, такую как TCP, то эти отбрасывания будут интерпретироваться как перегрузка, сигнализирующая передатчику о замедлении.
RED и другие варианты также решают проблему синхронизации TCP. Без RED все входящие хвостовые пакеты отбрасываются при наличии переполненного буфера. Для трафика TCP потеря пакетов в результате отбрасывания хвоста приводит к снижению скорости передачи и повторной передаче потерянных пакетов. Как только пакеты будут доставлены снова, TCP попытается вернуться к более высокой скорости. Если этот цикл происходит одновременно во многих разных разговорах, как это происходит в сценарии с отключением RED-free, интерфейс может испытывать колебания использования полосы пропускания, когда канал переходит от перегруженного (и сбрасывания хвоста) к незагруженному и недоиспользованному, поскольку все д throttled-back TCP разговоры начинают ускоряться. Когда уже синхронизированные TCP-разговоры снова работают достаточно быстро, канал снова становится перегруженным, и цикл повторяется.
RED решает проблему синхронизации TCP, используя случайность при выборе пакетов для отбрасывания. Не все TCP-разговоры будут иметь отброшенные пакеты. Только определенные разговоры будут иметь отброшенные пакеты, случайно выбранные RED. TCP-разговоры, проходящие через перегруженную линию связи, никогда не синхронизируются, и колебания избегаются. Использование каналов связи более устойчиво.
Управление задержкой буфера, Bufferbloat и CoDel
Здесь может возникнуть очевидный вопрос. Если потеря пакетов - это плохо, почему бы не сделать буферы достаточно большими, чтобы справиться с перегрузкой? Если буферы больше, можно поставить в очередь больше пакетов, и, возможно, можно избежать этой досадной проблемы потери пакетов. Фактически, эта стратегия больших буферов нашла свое применение в различных сетевых устройствах и некоторых схемах проектирования сети. Однако, когда перегрузка канала приводит к тому, что буферы заполняются и остаются заполненными, большой буфер считается раздутым. Этот феномен так хорошо известен в сетевой индустрии, что получил название: bufferbloat.
Bufferbloat имеет негативный оттенок, потому что это пример слишком большого количества хорошего. Буферы - это хорошо. Буферы предоставляют некоторую свободу действий, чтобы дать пачке пакетов где-нибудь остаться, пока выходной интерфейс обработает их. Для обработки небольших пакетов трафика необходимы буферы с критическим компромиссом в виде введения задержки, однако превышение размера буферов не компенсирует уменьшение размера канала. Канал имеет определенную пропускную способность. Если каналу постоянно предлагается передать больше данных, чем он может передать, то он плохо подходит для выполнения требуемой от него задачи. Никакая буферизация не может решить фундаментальную проблему пропускной способности сети.
Увеличение размера буфера не улучшает пропускную способность канала. Фактически, постоянно заполненный буфер создает еще большую нагрузку на перегруженный интерфейс. Рассмотрим несколько примеров, противопоставляющих протоколов Unacknowledged Datagram Protocol (UDP) и Transmission Control Protocol (TCP).
В случае VoIP-трафика буферизованные пакеты прибывают с опозданием. Задержка чрезвычайно мешает голосовой беседе в реальном времени. VoIP - это пример трафика, передаваемого посредством UDP через IP. UDP-трафик не подтверждается. Отправитель отправляет пакеты UDP, не беспокоясь о том, доберутся ли они до места назначения или нет. Повторная передача пакетов не производится, если хост назначения не получает пакет UDP. В случае с VoIP - здесь важно, пакет приходит вовремя или нет. Если это не так, то нет смысла передавать его повторно, потому что уже слишком поздно. Слушатели уже ушли. LLQ может прийти вам в голову как ответ на эту проблему, но часть проблемы - это слишком большой буфер. Для обслуживания большого буфера потребуется время, вызывающее задержку доставки трафика VoIP, даже если LLQ обслуживает трафик VoIP. Было бы лучше отбросить VoIP-трафик, находящийся в очереди слишком долго, чем отправлять его с задержкой.
В случае большинства приложений трафик передается по протоколу TCP через IP, а не по протоколу UDP. TCP - протокол подтверждений. Отправитель трафика TCP ожидает, пока получатель подтвердит получение, прежде чем будет отправлен дополнительный трафик. В ситуации bufferbloat пакет находится в переполненном, слишком большом буфере перегруженного интерфейса в течение длительного времени, задерживая доставку пакета получателю. Получатель получает пакет и отправляет подтверждение. Подтверждение пришло к отправителю с большой задержкой, но все же пришло. TCP не заботится о том, сколько времени требуется для получения пакета, пока он туда попадает. И, таким образом, отправитель продолжает отправлять трафик с той же скоростью через перегруженный интерфейс, что сохраняет избыточный буфер заполненным и время задержки увеличивается. В крайних случаях отправитель может даже повторно передать пакет, пока исходный пакет все еще находится в буфере. Перегруженный интерфейс, наконец, отправляет исходный буферизованный пакет получателю, а вторая копия того же пакета теперь находится в движении, что создает еще большую нагрузку на уже перегруженный интерфейс!
Эти примеры демонстрируют, что буферы неподходящего размера на самом деле не годятся. Размер буфера должен соответствовать как скорости интерфейса, который он обслуживает, так и характеру трафика приложения, который может проходить через него.
Одна из попыток со стороны сетевой индустрии справиться с большими буферами, обнаруженными вдоль определенных сетевых путей, - это контролируемая задержка, или CoDel. CoDel предполагает наличие большого буфера, но управляет задержкой пакетов, отслеживая, как долго пакет находится в очереди. Это время известно, как время пребывания. Когда время пребывания пакета превысило вычисленный идеал, пакет отбрасывается. Это означает, что пакеты в начале очереди-те, которые ждали дольше всего-будут отброшены до пакетов, находящихся в данный момент в хвосте очереди.
Агрессивная позиция CoDel в отношении отбрасывания пакетов позволяет механизмам управления потоком TCP работать должным образом. Пакеты, доставляемые с большой задержкой, не доставляются, а отбрасываются до того, как задержка станет слишком большой. Отбрасывание вынуждает отправителя TCP повторно передать пакет и замедлить передачу, что очень желательно для перегруженного интерфейса. Совокупный результат - более равномерное распределение пропускной способности для потоков трафика, конкурирующих за интерфейс.
В ранних реализациях CoDel поставлялся в устройства потребительского уровня без параметров. Предполагаются определенные настройки по умолчанию для Интернета. Они включают 100 мс или меньше времени двустороннего обмена между отправителями и получателями, а задержка 5 мс является максимально допустимой для буферизованного пакета. Такая конфигурация без параметров упрощает деятельность поставщиков сетевого оборудования потребительского уровня. Потребительские сети являются важной целью для CoDel, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки. Кроме того, сетевое оборудование потребительского уровня часто страдает от слишком большого размера буферов.