По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В обычной корпоративной сети доступ к серверам из филиалов организации может осуществляться, чаще всего, подключением к серверам, расположенным в центральном офисе. Но при расположении серверной инфраструктуры в облаке параметры связи рабочих станций с серверами будут зависеть уже не от канала связи от каждого конкретного филиала до центрального офиса, а от канала связи всех отделений организации с ЦОД облачного провайдера, чьими услугами пользуется организация для формирования облачной инфраструктуры.
Переход в облака поставил перед разработчиками ПО и сетевыми инженерами ряд новых условий, вызывающих задержку сигнала, которые им приходится учитывать для формирования качественного доступа к данным в облаке. Например, задержка длительностью 500мс приводит к снижению трафика Google на 20%, а задержка в 100мс сокращает продажи Amazon на 1%.
Время задержки может быть очень важным аспектом во время работы с виртуальными рабочими столами (VDI), потоковым вещанием, трейдингом, передовыми web-сервисами, базами данных, терминальными приложениями. Но задержка не столь критична для таких сервисов как электронная почта или работа с документами.
QoS и SLA
Существует проблема обеспечения необходимого качества обслуживания (QoS). Разные виды трафика имеют различные требования к рабочим характеристикам сети. Чувствительность видов трафика была взята из и показана в таблице 1
Таблица 1. Чувствительность различных приложений сетевым характеристикам
Тип трафика
Уровень чувствительности к сетевым характеристикам
Полоса
пропускания
Потери
Задержка
Джиттер
Голос
Очень низкий
Средний
Высокий
Высокий
Электронная коммерция
Низкий
Высокий
Высокий
Низкий
Транзакции
Низкий
Высокий
Высокий
Низкий
Электронная почта
Низкий
Высокий
Низкий
Низкий
Telnet
Низкий
Высокий
Средний
Низкий
Поиск в сети "от случая
к случаю"
Низкий
Средний
Средний
Низкий
Постоянный поиск в
сети
Средний
Высокий
Высокий
Низкий
Пересылка файлов
Высокий
Средний
Низкий
Низкий
Видеоконференция
Высокий
Средний
Высокий
Высокий
Мультикастинг
Высокий
Высокий
Высокий
Высокий
Рекомендации МСЭ-Т по обеспечению QoS для сетей описываются в рекомендациях Y.1540 - стандартные сетевые характеристики для передачи пакетов в сетях IP, и Y.1541 нормы для параметров, определенных в Y.1540.
Данные рекомендации важны для всех участников сети: провайдеров и операторов, пользователей и производителей оборудования. При создании оборудования, планировании развертывания и оценке сетей IP, оценка качества функционирования сети все будут опираться на соответствие характеристик требованиям потребителей.
Основные характеристики, рассматриваемые в рекомендации Y.1540:
производительность сети;
надежность сети/сетевых элементов;
задержка;
вариация задержки (jitter);
потери пакетов.
Подробнее о данных характеристиках следует прочитать в вышеназванных рекомендациях. В таблице 2 указаны нормы на определенными в Y.1540 характеристики и распределены по классам качества обслуживания (QoS).
Таблица 2 - Нормы для характеристик сетей IP с распределением по классам QoS
Сетевые
характеристики
Классы QoS
0
1
2
3
4
5
Задержка доставки пакета
IP, IPTD
100 мс
400 мс
100 мс
400 мс
1 с
Н
Вариация задержки
пакета IP, IPDV
50 мс
50 мс
Н
Н
Н
Н
Коэффициент потери
пакетов IP, IPLR
1х10 3
1х10 3
1х10 3
1х10 3
1х10 3
Н
Коэффициент ошибок
пакетов IP, IPER
1х10 4
1х10 4
1х10 4
1х10 4
1х10 4
Н
Примечание: Н не нормировано. Рекомендация Y.1541 устанавливает соответствие между классами QoS и приложениями:
Класс 0 приложения реального времени, чувствительные к джиттеру, характеризуемые высоким уровнем интерактивности (VoIP, видеоконференции);
Класс 1 приложения реального времени, чувствительные к джиттеру, интерактивные (VoIP, видеоконференции);
Класс 2 транзакции данных, характеризуемые высоким уровнем интерактивности (например, сигнализация);
Класс 3 транзакции данных, интерактивные;
Класс 4 приложения, допускающие низкий уровень потерь (короткие транзакции, массивы данных, потоковое видео)
Класс 5 традиционные применения сетей IP.
Таким образом некоторые из облачных сервисов вполне могут попадать в классы 0 и 1, а значит следует учитывать время задержки и стараться сделать так, чтобы она не превышала 100 мс.
Задержки в сетях
Подключение к облаку через VPN аналогично подключению к центральному офису организации по VPN, за исключением лишь того, что если в обычной корпоративной сети все филиалы организации подключались к центральному офису, то теперь подключение филиалов и центрального офиса в том числе будет осуществляться к ЦОД облачного провайдера.
Для проверки задержки в большинстве ОС используется команда ping, а для проверки пути прохождения пакета команда tracert, которые подробнее рассмотрим ниже.
Предположим, что домашняя сеть является подобием корпоративной сети малого предприятия. В таблице в приложении А собраны данные из статьи с указанием расположения ЦОД.
Воспользуемся этими данными чтобы проверить задержку сигнала от текущей домашней сети, расположенной в городе Москва, без учета VPN, до web-сервера некоторых компаний, владеющих, ЦОД, расположенных в разных городах, тем самым проверяя разницу в задержке в зависимости от расположения ЦОД облачного провайдера.
Для проверки задержки воспользуемся "Командной строкой" Windows и командами ping и tracert. Команда ping используется для проверки целостности и качества соединения в сети на основе протоколов TCP/IP. Команда tracert строит маршрут через коммутационные узлы между компьютером и конечным сервером и выводит их IP-адреса и время
задержки. На рисунках 1 и 2 представлена системная справка по командам, соответственно, tracert и ping.
Проведем тест проверки задержки до домена DataLine dtln.ru, расположенного ближе всего к домашней сети (рисунки 3 и 4).
Как видно из результатов на рисунке 5.3, было передано и получено 4 пакета объемом 32 байта. Время обмена одним пакетом составило 1 миллисекунду.
Команда tracert вывела следующие данные:
1, 2, 3 - номер перехода;
<1 мс <1 мс <1 мс время ответа для 3-х попыток (в данном случае все попытки менее 1 мс);
185.3.141.232 IP-адреса (в данном случае IP-адрес домена
dtln.ru)
Согласно проверке данного IP на сайте 2ip.ru, данный домен базируется по тому же адресу на карте, что и указано в таблице в приложении Б. Таким образом можно сделать вывод, что web-сервер большинства компаний из списка вероятнее всего находится на территории одного из их ЦОД, но даже если и нет, то позволяет сделать выводы о доступности ресурса.
Аналогично проверим ping для остальных компаний, результаты представим на рисунке 5.5. В качестве опорного времени задержки будет использовано среднее и максимальное время приема-передачи.
Из данных рисунка 5 можно сделать вывод, что среднее значение времени задержки в пределах Москвы из сети, также находящейся в пределах Москвы, чаще всего не превышает 10мс.
Можно сравнить данные значения с ping до серверов Amazon Web Services в разных регионах с сайта cloudping.info (рисунок 6).
VPN без шифрования теоретически позволил бы сократить эту задержку в связи с использованием "прямого туннеля" между "офисом" и ЦОД. Шифрование будет вносить уже свою задержку, проверить которую в данных условиях нет возможности.
В локальных сетях корпоративной сети и сети ЦОД задержка исчисляется в микросекундах. В сети ЦОД предъявляются высокие требования к быстродействию сети, современные решения Ethernet для ЦОД должны быть широкополосными и поддерживать скорости 10, 25, 40, 50, 100 Гбит/с, обеспечивать низкие задержки до 1-2 мкс для связи серверов (через три коммутатора), и многие другие.
Скорость интернет-канала
Передача видео через сети связи, будь то видео с камер наблюдения или же видеоконференции, являются одними из самых требовательных с скорости передачи данных. Если для работы с документами может быт достаточно скорости в 100 Кбит/с, то для передачи видео понадобится уже примерно 2 Мбит/с.
Для некоторых приложений, таких как IP-телефония, желательно, чтобы уровень задержек был низким, а мгновенная пропускная способность канала была больше определенного порогового значения: не ниже 24 Кбит/с для ряда приложений IP-телефонии, не ниже 256 Кбит/с для приложений, обрабатывающих видеопоток в реальном времени. Для некоторых приложений задержки не так критичны, но, с другой стороны, желательна высокая пропускная способность, например, для передачи файлов.
Например, компания Ivideon предлагает услуги облачного видеонаблюдения, и у них на сайте даются следующие требования к интернет-каналу для разного качества видеопотока. Данные представлены в таблице 3.
Таблица 3 Требования к интернет-каналу для одной камеры видеонаблюдения при разных разрешения при частоте 25 кадров/сек
Разрешение Качество изображения
Рекомендуемая скорость
1280х720 (1Mpx) /25к/с
1 Мбит/с
1920x1080 (2Mpx) /25к/с
2 Мбит/с
2048x1536 (3Mpx) /25к/с
2 Мбит/с
2592x1728 (4Mpx) /25к/с
2 Мбит/с
Но для работы с терминальными сессиями достаточно канала в 128-256 Кбит/с на пользователя. Для 50 пользователей понадобится 6.25 Мбит/с.
Компания 1cloud.ru при выборе ширины канала связи предлагает скорость соединения в диапазоне от 10 до 100 Мбит/с для доступа к виртуальному серверу.
Внутри облака сетевые соединения между виртуальными машинами имеют пропускную способность в 1 Гбит/с.
RDP-сессия
Для теста потребления трафика при использовании удаленного подключения RDP был проведен эксперимент.
Два персональных компьютера находятся в одной локальной сети и подключены к интернету. Один выступает сервером удаленного доступа, второй подключается к нему посредством встроенной в Windows программы
"Подключение к удаленному рабочему столу" по протоколу RDP. На сервере запускается видео в интернете. Для захвата трафика и анализа используется ПО Wireshark
Параметры подключения:
размер удаленного рабочего стола 1920х1080
глубина цвета 15 бит
выбранная скорость соединения 56 Кбит/с
дополнительные возможности отключены (рисунок 7)
Wireshark программа для захвата и анализа сетевого трафика. Данная программа работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс, и мощнейшую систему фильтров.
Во время подключения к удаленному рабочему столу программа замеряла отправленные и поступившие пакеты данных. Эти пакеты были отфильтрованы по IP-адресу сервера, а также по протоколу RDP. Интерфейс программы представлен на рисунке 8.
График ввода/вывода данных по IP-адресу сервера по протоколу RDP представлен на рисунке 9.
На графике на рисунке 9 видно два "всплеска" данных, т.е. две сессии подключения к серверу. Во время первой сессии проводилась работа с тяжеловесным графическим приложением. Во время второй сессии было включено видео, затем производился web-серфинг в браузере машины с некоторыми графическими материалами на странице.
Как видно по графику, в пиковый момент была передача данных 5.5 Мбит/с. В последние моменты web-серфинга 0,65 Мбит/с.
Таким образом можем сделать вывод, что протокол RDP не укладывается в ранее заявленный диапазон до 128 Кбит/с. Однако стоит учитывать, что RDP-сессия изначально очень требовательна к сети и является, по сути, передачей видеотрафика.
Общедоступной информации в сети для анализа влияния облачной инфраструктуры на сеть, по крайней мере в русскоязычном сегменте интернета, чрезвычайно мало. Исследований по теме облачных вычислений недостаточно для заключения результата, и, в основном, это анализы финансовых затрат или производительности серверов.
Наиболее подходящей темой для дискуссий на тему влияния облачной инфраструктуры на сеть могут служить только качество обслуживания (QoS) и договор о предоставлении услуг SLA, но данные темы слишком обширны и требует более углубленного внимания, а вопросы, связанные с ними, требуют внимания соответствующих специалистов.
Ну просто очень частый кейс: создается виртуальная машина на Linux ОС (Hyper-V или VMware, не важно), которая работает длительное время. Но в один прекрасный момент, память сервера переполняется и приходится расширять диск. В виртуализации (гипервизоре) это сделать очень просто - нарастить виртуальный диск с физического. А что делать внутри виртуалки, где живет Linux/CentOS?
В статье мы расскажем, как расширить пространство памяти (диск) на сервера под управлением Linux/CentOS, последовательно управляя PV (Physical Volume, физические тома), VG (Volume Group, группа томов) и LV (Logical Volume, логические разделы).
А вообще мы можем расширить диск или нужно создать новый?
Это очень важный пункт. Обязательно проверьте вот что: дело в том, что диск разделенный на 4 раздела более не сможет быть расширен. Проверить это легко. Подключаемся к серверу CentOS и вводим команду fdisk -l:
# fdisk -l
Disk /dev/sda: 187.9 GB, 187904819200 bytes
255 heads, 63 sectors/track, 22844 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 25 200781 83 Linux
/dev/sda2 26 2636 20972857+ 8e Linux LVM
Если вывод команды у вас выглядит так, как показано выше - все хорошо. У вас пока только два раздела - /dev/sda1 и /dev/sda2. Можно создать еще два.
Однако, если вывод команды будет выглядеть вот так:
# fdisk -l
Disk /dev/sda: 187.9 GB, 187904819200 bytes
255 heads, 63 sectors/track, 22844 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 25 200781 83 Linux
/dev/sda2 26 2636 20972857+ 8e Linux LVM
/dev/sda3 2637 19581 136110712+ 8e Linux LVM
/dev/sda4 19582 22844 26210047+ 8e Linux LVM
Это означает, что для решения задачи расширения памяти на сервере вам нужно создавать новый диск, а не расширять предыдущий. Мы рассматриваем первый вариант, когда у вас еще есть возможность создавать разделы. Погнали!
Создаем новую партицию
Проверяем что у нас на физических дисках командой fdisk -l
# fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 391 3036285 8e Linux LVM
Сервер видит 10.7 ГБ места на диске. Начинаем создавать новую партицию (раздел) командой fdisk /dev/sda. После запроса ввода команды, указываем n, чтобы создать новую партицию:
# fdisk /dev/sda
The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
В следующем разделе конфигурации, указываем ключ p чтобы создать раздел. Тут будьте внимательны - самый первый пункт нашей статьи - у вас должно быть на этот момент строго меньше 4 партиций на диске!
Command action
e extended
p primary partition (1-4)
p
На следующем экране задаем номер для партиции. Так как у нас уже есть партиции /dev/sda1 и /dev/sda2, то следуя порядковому номеру, мы указываем цифру 3:
Partition number (1-4): 3
В следующем пункте, мы рекомендуем нажать Enter дважды, то есть принять предложенные по умолчанию значения:
First cylinder (392-1305, default 392):
Using default value 392
Last cylinder or +size or +sizeM or +sizeK (392-1305, default 1305):
Using default value 1305
Отлично. Теперь мы меняем типа нашего раздела. Для этого, в следующем меню нажимаем ключ t, указываем номер партиции, который только что создали (напомним, это был номер 3), 3, а в качестве Hex code укажем 8e, а дальше просто Enter:
Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)
Готово. Мы вернулись в основное меню утилиты fidsk. Сейчас ваша задача указать ключ w и нажать Etner, чтобы сохранить опции партиций на диске:
Command (m for help): w
После, что самое важное этого метода - перезагружать ничего не нужно! Нам просто нужно заново сканировать партиции утилитой partprobe:
# partprobe -s
Если команда выше не работает, то попробует сделать с помощью partx:
# partx -v -a /dev/sda
И если уже после этого у вас не появляется новая партиция - увы, вам придется согласовать время перезагрузки сервера и перезагрузить его. Успешным результатом этого шага будет вот такой вывод команды fdisk, где мы видим новую партицию:
# fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 391 3036285 8e Linux LVM
/dev/sda3 392 1305 7341705 8e Linux LVM
Расширяем логический раздел LV с новой партиции
Теперь наша задача следующая: создаем физический том (PV) из новой партиции, расширяем группу томов (VG) из под нового объема PV, а затем уже расширяем логический раздел LV. Звучит сложно, но поверьте, это легко!
Итак, по шагам: создаем новый физический том (PV). Важно: у вас может быть не /dev/sda3, а другая, 4, например, или вообще /dev/sdb3! Не забудьте заменять в командах разделы, согласно вашей инсталляции.
# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
Отлично. Теперь находим группу томов (VG, Volume Group). А точнее, ее название. Делается это командой vgdisplay:
# vgdisplay
--- Volume group ---
VG Name MerionVGroup00
...
Найдено. Наша VG называется MerionVGroup00. Теперь мы ее расширим из пространства ранее созданного PV командой vgextend:
# vgextend MerionVGroup00 /dev/sda3
Volume group "MerionVGroup00" successfully extended
Теперь расширяем LV из VG. Найдем название нашей LV, введя команду lvs:
# lvs
LV VG Attr LSize
MerionLVol00 MerionVGroup00
MerionLVol00 - найдено.Расширяем эту LV, указывая до нее путь командой lvextend /dev/MerionVGroup00/MerionLVol00 /dev/sda3:
# lvextend /dev/MerionVGroup00/MerionLVol00 /dev/sda3
Extending logical volume MerionLVol00 to 9.38 GB
Logical volume MerionLVol00 successfully resized
Почти у финиша. Единственное, что осталось, это изменить размер файловой системы в VG, чтобы мы могли использовать новое пространство. Используем команду resize2fs:
# resize2fs /dev/MerionVGroup00/MerionLVol00
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/MerionVGroup00/MerionLVol00 is mounted on /; on-line resizing required
Performing an on-line resize of /dev/MerionVGroup00/MerionLVol00 to 2457600 (4k) blocks.
The filesystem on /dev/MerionVGroup00/MerionLVol00 is now 2457600 blocks long.
Готово. Проверяет доступное место командой df -h. Enjoy!
Получаете ошибку в resize2fs: Couldn't find valid filesystem superblock
Если вы получили ошибку вида:
$ resize2fs /dev/MerionVGroup00/MerionLVol00
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/MerionVGroup00/MerionLVol00
Couldn't find valid filesystem superblock.
Это значит, что у вас используется файловая система формата XFS, вместо ext2/ext3. Чтобы решить эту ошибку, дайте команду xfs_growfs:
$ xfs_growfs /dev/MerionVGroup00/MerionLVol00
meta-data=/dev/MerionVGroup00/MerionLVol00 isize=256 agcount=4, agsize=1210880 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0
data = bsize=4096 blocks=4843520, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Как тебе такое, Илон Маск?
В прошлой статье мы рассказывали о ресурсе HIBP, на котором можно, проверить находится ли ваш email или пароль в базе взломанных учётных данных. В этой статье расскажем о расширении от Google, которое может выполнять такую же проверку автоматически на любом сайте, где вы вводите учётные данные, используя браузер Google Chrome.
Расширение, описанное в данной статье, актуально только для пользователей браузера Google Chrome. Остальным же, мы надеемся, будет просто полезно ознакомиться с возможностями решения.
Похоже, что факт обнаружения баз слитых учёток Collection #1 и последующих более крупных Collection #2-5, не остался без внимания Google. Потому что 5 февраля (в день безопасного Интернета, кстати) они объявили о создании сразу двух расширений, которые призваны сделать процесс работы с вэб-ресурсами и приложениями ещё более безопасным. Про одно из них мы бы хотели рассказать в нашей статье.
Password Checkup
Проверяет учётные данные, которые вы вводите на каждом сайте или в приложении через Google, по базе из свыше 4 миллиардов взломанных логинов и паролей. Если расширение обнаруживает ваши логин и пароль (то есть оба типа данных, которые необходимы для получения доступа к вашему аккаунту) в списке взломанных, то оно генерирует оповещение с предложением сменить скомпрометированные данные. При этом, расширение не будет уведомлять о том, что вы используете слабый пароль или о том, что ваш старый, не актуальный пароль был скомпрометирован.
Google заявляет, что разрабатывал расширение так, чтобы учетные данные, которые вы вводите, никогда не попали не только в злоумышленникам, но и в сам Google, в этом им помогали эксперты в области криптографии Стэндфордского Университа.
Итак, как это работает? Когда вы вводите на каком-либо сайте свой логин и пароль расширение обращается к серверам Google для того, чтобы проверить находятся ли введённые учётные данные в списке скомпрометированных. При этом, в запросе не передаются сами логин и пароль. То есть расширение опрашивает сервер, не передавая туда запрашиваемую информацию. При этом, важно исключить возможность использования расширения злоумышленниками, которые будут брутить сайты и пробовать получить от расширения информацию о скомпрометированных учётках. Для этого в расширении применяется сразу несколько технологий шифрования, многоразовое хэширование вводимой информации, а также технологии Private Set Intersection (PSI) и k-annonimity.
Google имеет в своём распоряжении базу из взломанных учётных данных, содержащих около 4 миллиардов записей. Однако, это не учётные данные в открытом виде, а их захэшированная и зашифрованная копия, ключ от которой известен только Google.
Каждый раз, когда вы вводите свой логин и пароль, расширение Password Checkup будет отправлять на сервера Google захэшированную копию этих данных, ключ от которых будет известен только вам.
В свою очередь на сервере Google эта копия также будет зашифрована специальным ключом. Последнее преобразование происходит локально в самом расширении - полученная копия от Google дешифруется и если результат сходится с тем хэшом скомпрометированных учётных данных, что хранится на сервере Google - то пользователю выводится Алерт с рекомендациями по смене пароля.
Если вы пользуетесь браузером Google Chrome, то рекомендуем установить данное расширение, чтобы обезопасить свои аккаунты от доступа к ним третьих лиц. И никогда, пожалуйста, не используйте одни и те же пароли на разных сайтах.