Технологии бесклассовой междоменной маршрутизации CIDR

Из-за несовершенства протоколов маршрутизации, основанной на классах, приводившей к сбоям в разросшемся интернете, была внедрена технология CIDR (Classless Inter-Domain Routing).

Суть технологии заключается в следующем: каждому поставщику услуг интернет должен назначаться непрерывный диапазон в пространстве IP-адресов. При таком подходе адреса всех сетей каждого поставщика услуг имеют общую старшую часть – префикс. Поэтому маршрутизация на магистралях интернет может осуществляться на основе префиксов.

Агрегирование адресов позволяет уменьшить объем таблиц маршрутизаторов всех уровней и, следовательно, ускорить работу маршрутизатора и повысить пропускную способность.

Деление IP-адреса на номер сети и номер узла происходит не на основе нескольких старших бит как в классовой сети, а на основе маски переменной длины, назначаемой поставщиком услуг.

 

Пример записи IP-адреса в бесклассовой нотации:

192.0.2.32/27

Октеты IP-адр. 192 0 2 32

Биты IP-адр. 11000000 00000000 00000010 00100000

Биты маски подсети 11111111 11111111 11111111 11100000

Октеты маски 255 255 255 224

 

Внедрение технологии CIDR позволяет решить 2 основные задачи.

1. Более экономное расходование адресного пространства. Получая в свое распоряжение адрес сети, например класса С, некоторые организации не используют весь возможный диапазон узлов, т.к. их сети менее 255 узлов. CIDR позволяет получать в пользование столько адресов, сколько реально необходимо.

2. Уменьшение числа записей в таблицах маршрутизаторов за счёт объединения маршрутов – одна запись в таблице маршрутизации может представлять большое количество сетей. Для всех сетей, номера которых начинаются с одинаковой последовательности чисел, в таблице маршрутизации может быть предусмотрена одна запись.

 

Технология CIDR успешно используется в текущей версии IP4 и поддерживается большинством протоколов маршрутизации.

MSSQL

В современной версии БД позволяют обеспечивать высокую производительность, масштабируемость, простоту использования и эффективную работу с данными.

Масштабируемость – подсистема хранилища, которая работает с физическими файлами БД, поддерживает масштабирование от очень маленьких до очень больших БД. SQLServer может поддерживать до 64 ГБ ОЗУ и до 32 ГБ процессор.

Простота использования – усовершенствованные возможности администрирования помогают администратору БД автоматизировать рутинные операции и выполнять управление серверами централизованно через конфигурацию сервера с помощью различных служб.

Расширенная подсистема хранилища – реляционный сервер БД SQL имеет 2 лавных узла: реляционная подсистема и подсистема хранилища. Эти 2 подсистемы работают независимо, взаимодействуя др.с др. посредством собственных компонент данных как OLE DB. Реляционная подсистема использует интерфейс подсистемы хранилища, который состоит из сервисов, позволяющих взаимодействовать с основными компонентами хранилища БД.

Основные задачи подсистемы хранилища:

1. Обеспечение функциональности, позволяющее улучшить и облегчить использование и управление компонентами хранилища.

2. Управление буфферизацией данных и всего ввода/вывода физических файлов.

3. Контроль параллелизма, управление транзакциями, блокировок и журналирования.

4. Управление файлами и физическими страницами, используемыми для хранения данных.

5. Восстановление после системных ошибок.

 

Подсистема хранилища в SQLServer предлагает возможности, которые привносят простоту и физическую гибкость, сокращая при этом потребность в планировании, размещении и настройки производительности. Ключевая цель группы подсистем хранилища состоит в том, чтобы сократить затраты на настройку сервера для достижения его максимальной работы.

Ядро сервера может динамически корректировать эти параметры в зависимости от ситуации, в которой оказывается БД, используя специальные адаптивные алгоритмы.

 

Основные расширения, реализованные в подсистеме хранилища MSSQL

Application lock manager. Если есть необходимость управления параллельным доступом к определяемым приложениям и ресурсам, новые хранимые процедуры позволяют блокировать эти ресурсы, используя данный менеджер.

Database console commands. Консольные команды БД. Команды из состава DBCC могут выполняться во время обслуживания сетевых запросов, не блокируя изменения. DBCC выполняется параллельно на нескольких процессорах.

Database options. Все опции БД можно изменять, используя инструкции Alter DataBase, что упрощает администрирование.

Differential backups. Дифференциальное резервное копирование в SQLServer работает быстрее из-за расширения, которое отслеживает изменения в БД на уровне экстендов.

Dynamic tuning. Динамическая настройка. Используя адаптивные динамические алгоритмы, сервер автоматически корректирует изначально статические параметры настройки конфигурации.

In-row text. Для таблиц, которые имеют небольшие, но часто используемые текстовые поля маленькие текстовые значения могут сохраняться на той же странице, что и данная запись, а не на специальной странице для текстовых значений.

Index builds in parallel. Параллельное создание индексов. Создание индексов автоматически задействует все процессоры, выделенные для параллельного обслуживания запросов.

Index read ahead. Упреждающее чтение индексов. Было добавлено в качестве расширения для увеличения производительности сканирования индексов.

Large memory support. Поддержка памяти большого размера. Использует расширение текущих версий Windows и позволяет поддерживать большой объем физической памяти (64 ГБ).

Locking. Блокирование. Возможности менеджера блокировок расширены и позволяют обнаруживать тупиковые блокировки и для таких ресурсов, как потоки и память. Усовершенствование параллелизма также сокращает число тупиковых блокировок.

Logical log marks. Метки в журнале транзакций. С помощью команд T-SQL можно создать закладку в файле журнала транзакций, чтобы потом можно было выполнить восстановление БД до установленной метки.

Optimized I/o read ahead. Оптимизированное упреждающее чтение ввода/вывода. SQLServer выполняет большой объем операций упреждающего последовательного чтения для каждого файла, затронутого запросом. Оптимизатор повышения производительности использует последовательный ввод/вывод с упреждающим чтением при сканировании таблиц и индексов.

Recovery models. Модели резервирования. Используя их можно задать в базе данных уровень журналирования операций, что добавляет гибкости управления журналу транзакций. Модель резервирования может изменяться интерактивно.

Shared table scans. Разделяемые сканирования таблиц. Могут использовать результаты уже выполняющихся сканирований таблицы, что сокращает дисковый ввод/вывод.

Snapshot backups. Резервирование снимка базы использует технологии современных хранилищ, что позволяет выполнять резервирование и восстановление практически мгновенно.

Space-efficient empty tables and indexes. В последней версии MSSQL больше не распределяют на диске пустые странице для пустых таблиц и индексов.

 

Лекция 6

Службы и различные возможности SQLServer

Работа с данными.

Более эффективное чтение данных.

Данные передаются между сервером и пользователем посредством нескольких транзакций. Приложение или пользователь инициирует задачу и БД передает ее на исполнение процессору запроса и возвращает результат. Процессор запросов обслуживает задачу, принимая, интерпретируя и исполняя инструкции на T-SQL. Например, когда в сеансе пользователя передается инструкция Select, будут исполнены шаги:

1. Реляционная подсистема оптимизирует инструкцию и компилирует ее в план исполнения.

2. Реляционная подсистема интерпретирует план исполнения и чтобы собрать необходимые данные, отправляет запросы подсистеме хранилища.

3. Реляционная подсистема объединяет все данные, возвращенные подсистемой хранилища в окончательный результирующий набор.

 

Разделяемые сканирования

В SQLServer несколько запросов могут совместно использовать результаты выполняющегося сканирования таблиц, что может повысить производительность запросов, работающих с большими БД. Например, когда запрос сканирует без упорядочения большую таблицу, поток страниц направляется в кэш, в котором создается место для этих данных.

Если бы в это время был получен другой запрос к этой же таблице, без подобного кэширования пришлось бы создавать дополнительный операции дискового ввода/вывода тех же самых страниц.

Когда возможны разделяемые сканирования, всегда стоит пытаться оптимизировать запрос или подбирать индексы, т.к. сканирование таблиц будет уступать производительности и использованию хорошо подобранного индекса.

Параллелизм

Для сохранения последовательности транзакций при обращении к данным большого числа пользователей, подсистема хранилища блокирует ресурсы, что позволяет управлять связями на уровне строк, страниц, ключей, индексов и таблиц БД. Блокируя ресурс на время его изменения, ядро препятствует одновременному внесению изменений в одни и те же данные сразу несколькими пользователями. SQLServer динамически накладывает блокировки на разных уровнях детализации данных, стараясь использовать блокировку с наименьшими ограничениями.

Посредством специального процесса – отложенной фиксации – подсистема хранилища может активизировать доступ к страницам данных, фиксируя страницы только тогда, когда они же требуются другим продолжающимся процессам. Если же таких процессов нет, действует только одна фиксация для всех операций страниц.

Таблицы и индексы

Поскольку таблицы и индексы подвержены росту, SQLServer распределяет новые страницы группами по 8 страниц – экстенды. В SQLServer процессор запросов автоматически использует индексированное представление в тех случаях, когда это может оптимизировать план исполнения запроса.

Индексированные представления могут повысить производительность запросов данных, которые редко изменяются и часто используются для сложных объединения или запросов с вычислениями.

Новые типы данных

По мере развития SQLServer в нем появляются новые типы данных:

1. bigint – целочисленный 8-ми байтный тип,

2. sql_variant – позволяет хранить значения данных различных типов,

3. table – табличные данные, является полезным для оптимизации производительности.

Табличные переменные позволяют более эффективно использовать базу tempdb и работают быстрее, чем временные таблицы.

Индексы

Обращения к данным оптимизируются с помощью индексов. Поскольку требования к индексированию основываются на специфике использования данных, неправильный выбор индексов является одной из самых распространенных причин медленного исполнения запроса БД.

Типовая схема обслуживания индексов должна предусматривать периодические исследования условия использования индексов. Проверку схемы индексации и подстройку или оптимизацию индексов для текущих условий использования, отключая или создавая новый индекс.

Построение индексов

Когда создается индекс, подсистема хранилища делает выборку записей и определяет самый эффективный способ использования ресурсов сервера для создания индексов. Разные опции при этом позволяют управлять тем, какие системные ресурсы будут при этом распределены.

 

Ресурс	Команда	Опции	Описание
TempDB	create index	Sort in tempdb	Задействует распределяемое в tempdb дисковое пространство для сортировки при создании индекса. Способствует повышению пропускной способности ввода/вывода, если tempdb находится на нескольких дисках.
Память	sp_config	Index create memory	Определяет объем памяти, используемый при создании любых индексов.
СPU	sp_config	Max degree of parallelism	Ограничивает число процессоров, используемых в параллельных операциях.

Еще одним механизмом обеспечения масштабируемости является параллельное создание индексов. Этот процесс активизируется автоматически, когда серверу поступает инструкция по созданию индексов.

Подсистема хранилища определяет требования к данным и создает отдельные потоки.

Дефрагментация индексов

SQLServer поддерживает реорганизацию индексов «налету». Она не сильно влияет на производительность других операций и может быть остановлена и перезапущена в любой момент без потерь в своей работе. Вследствие вставок, удалений и изменений данных в таблице, страницы индексов могут оказаться фрагментированными, что снижает эффективность запросов.

Возможно использование команды DBCC SHOWCOUNTING, чтобы наблюдать и анализировать процесс фрагментации.

Если индекс фрагментирован, можно, используя команду DBCC INDEXDEFRUG, выполнить дефрагментацию индекса. Таким образом, можно поднять производительность операций чтения, за счет увеличения плотности заполнения страниц. Из-за чего во время выборки данных будет считываться меньшее их число.

Регистрация и регенерация.

Журнал транзакция представляет собой последовательность записей об изменениях БД. Регистрационные записи, сгенерированные транзакциями, сохраняются на диске в момент завершения своих транзакций. В том время как, страницы данных изменяемые транзакции сразу на диск не записываются, но сохраняются в кэш SQLServer для записи на диск спустя некоторое время.

Отсрочка записи на диск повышает эффективность массового доступа к страницам данных и позволяет избежать прерывания сканирования. Принудительная запись в файл журнала на диске позволяет гарантировать, что полностью завершенные операции не будут потеряны, если сервер будет остановлен.

Механизм восстановления (recovery) гарантирует, что база данных остается транзакционно непротиворечива до момента, пока она не станет доступна. Если БД транзакционно непротиворечива в ней будут отражены все завершенные операции, а любые незаконченные действия будут отменены.

Процесс восстановления приводит данные в совместимое с журналом транзакций состояние. Восстановление, выполняемое во время запуска SQLServer, называют restart/startup recovery. Восстановление из резервной копии, которое обычно необходимо из-за отказа дисков – media recovery.

Восстановление имеет 2 стадии:

1. redo – повторяет все изменения до искомой метки в журнале транзакций.

2. Undo – отменяет все действия, выполненные транзакциями, которые были активны на момент времени, где завершилась стадия повтора redo.

Для ускорения restart/recovery SQLServer использует контрольные точки, которая сбрасывает все измененные на момент ее прохождения страницы данных из буфферного кэш на диск.

Логические метки журнала

В SQLServer введена возможность помечать транзакции в файле журнала регистраций транзакций. Если понадобится восстановить БД, возможно указать метку, которая использовалась во время исполнения транзакции, вместо того, чтобы использовать отметку времени.

Чтобы пометить таким образом транзакцию используется именованная инструкция:

BEGIN TRANSACTION с параметром WITH MARK.

Восстановление может происходить до или включая помеченную транзакцию.

RESTORE LOG WITH…

Также возможно использование метки и для распределения транзакций – распределенные метки. Они необходимы при восстановлении множества связанных БД, которые должны находиться в транзакционно непротиворечивом состоянии.

Такие связанные БД могут размещаться как на одном, так и на разных экземплярах SQLServer.

Можно периодически создавать распределенные метки для группы таких БД, например каждые 5 минут. Если журнал транзакций одной из БД будет поврежден, потребуется вернуть всю группу БД в предшествующее состояние.

Использование распределенных меток снижает необходимость координации и точной синхронизации резервных копий нескольких связанных БД.

 

Лекция 7