Консорциум ISC представил (https://www.isc.org/blogs/kea-1-1-released/) релиз DHCP-сервера Kea 1.1.0 (http://kea.isc.org), изначально развивавшегося в рамках проекта BIND 10, но отделённого от DNS-сервера в отдельный продукт, идущий на смену классическому ISC DHCP. Исходные тексты проекта распространяются под лицензией Mozilla Public License (MPL) 2.0 (https://www.opennet.ru/opennews/art.shtml?num=32726), вместо ранее применяемой для ISC DHCP лицензии ISC License.
DHCP-сервер Kea основан на технологиях BIND 10 и построен (https://www.opennet.ru/opennews/art.shtml?num=36235) с использованием модульной архитектуры, подразумевающей разбиение функциональности на разные процессы-обработчики. Продукт включает в себя полнофункциональную реализацию сервера с поддержкой протоколов DHCPv4 и DHCPv6, способную заменить собой ISC DHCP. В Kea встроены средства динамического обновления DNS-зон (Dynamic DNS), поддерживаются механизмы обнаружения серверов, назначения адресов, обновления и переподключения, обслуживания информационных запросов, резервирования адресов для хостов и PXE-загрузки. В реализации DHCPv6 дополнительно предусмотрена возможность делегирования префиксов. Для взаимодействия с внешними приложениями предоставляется специальный API. Возможно обновление конфигурации на лету без перезапуска сервера.Информация о выделенных адресах и параметрах клиентов может храниться в разных типах хранилищ - в настоящее время предоставляются бэкенды для хранения в файлах CSV, СУБД MySQL и PostgreSQL. Параметры резервирования хостов могут быть заданы в файле конфигурации в формате JSON или в виде таблицы в MySQL. В состав входит инструмент perfdhcp для измерения производительности сервера DHCP и компоненты для сбора статистики. Kea демонстрирует неплохую производительность, например, при использовании бэкеда MySQL сервер может выполнить 1000 присвоений адресов в секунду (около 4000 пакетов в секунду), а при использовании бэкенда memfile производительность достигает 7500 присвоений в секунду.
Новые возможности Kea 1.1:
- Возможность хранения базы резервирования хостов (для DHCPv4 и DHCPv6) в бэкендах MySQL или PostgreSQL. Из соображений безопасности хранимая в СУБД MySQL или PostgreSQL база резервирования хостов может быть настроена на доступ в режиме только для чтения, в этом случае Kea может только получать сведения о резервировании, но не имеет полномочий по дополнению или обновлению базы;
- Значительно расширены возможности по резервированию хостов, добавлена поддержка резервирования специфичных опций DHCP, резервированя siaddr, sname, полей сообщений DHCPv4 и множественных префиксов/адресов IPv6;
- Расширена система классификации клиентов, в которой для разделения клиентов на классы в конфигурации задаются условные логические выражения, оценивающие содержимое входящих пакетов DHCPv4 и DHCPv6. Клиент может принадлежать сразу к нескольким классам. В логических выражениях могут использоваться операторы (equal, not, and, or, substring и concat), литералы (строки, IP, целые числа), операции проверки опций и содержимого, функции разбора полей на составные части и т.п.- Возможность привязки параметров к сторонним библиотекам-обработчикам в основном файле конфигурации Kea, без использования внешних механизмов для организации передачи информации библиотеке;
- Поддержка конфигураций DHCPv4-over-DHCPv6, в которых клиенты IPv6-сетей могут взаимодействовать с сервером DHCPv4;- Реализация бэкенда хранения данных в СУБД Apache Cassandra (https://www.opennet.ru/opennews/art.shtml?num=43298). Бэкенд пока имеет статус экспериментальной разработки и ограничен возможностью хранения информации о выделении IP-адресов (lease), т.е. не подходит для размещения базы резервирования хостов.
URL: https://www.isc.org/blogs/kea-1-1-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=45276
DHCP-данные в кассандре? Нифига ж себе, это где такое может понадобиться?
там где много данных
больше 2^32 записей?
ipv6
Какая нах разница какой там IP v4/v6?
2^31 хостов в рамках одной DHCP сети, пускай даже с dhcp relay'ями, это где такое видано?!
Система умный дом же, нанороботы, светлое будущее. У каждой пылинки свой IP.
Заранее готовятся.
> 2^31 хостов в рамках одной DHCP сети, пускай даже с dhcp relay'ями,
> это где такое видано?!Я тоже обратил внимание на "сервер может выполнить 1000 присвоений адресов в секунду". Звчем?! Но, если 2^31 хостов в рамках одной DHCP сети одновременно включаются, тогда действительно необходима такая скорость.
Сферический конь в вакууме.
Сеть не обязательно домашняя. ISP в своей деятельности DHCP используют весьма и весьма широко. Масштабы применения и какие извращения накручиваются для достижения нужного функционала со стандартным isd dhcp админам локалок могут только в кошмарах увидеть.С новым сервером масштабы костылинга должны уменьшиться на пару порядков.
Да понятно, что не домашняя - те же мобильщики с ходу приходят в голову. Вот и назвали бы цифирки. Потому что не верится - с десятком миллионов записей даже mysql какой-нибудь справится запросто, а больше там вроде и не будет.Классический use-case для Кассандры - это интенсивная запись лога. Но понятие "интенсивная" и единицы тысяч запросов в секунду для выдачи адресов в моём понимании не слишком совместимы.
1000*60*60*24*365=31536000000 это где же где столько серверов взять? или это такие накладные расходы? или аренда до скончания веков?
Если 2^31 хостов одновременно включатся - с такой скоростью присвоения потребуется всего-то месяц, чтобы они все присвоились :) Ну и канальчик до DHCP гигабит в 10 :)
Хм. За собой boost тянет и помечен пока как нестабильный.
Нестабильным помечен только бэкенд для Casandra, сам kea ещё с версии 1.0 идёт как готовый для промышленного применения.
> За собой boost тянетНе любите бюсты?
уж больно тяжелые. на source-based сборка буста это было то ещё развлечение.
Какое развлечение? На генте с древним i3 собирается за 10 минут.
> Какое развлечение? На генте с древним i3 собирается за 10 минут.не знаю, на P3 было долго. относительно других либ, естессно.
Я так понимаю, уже сделали поддержку "option 82"?
Написано же "основан на технологиях BIND 10". Значит - "лучшее, конечно, впереди!" )
Только для DHCPv6 и только на чтение, свою реализацию нужно делать от примеров кода на C++
Судя по всему только частично.
"Host reservations by client identifier, DUID and circuit-id have been added in Kea 1.1.0."
Резервировать непосредственно по опции 82 - тут болт. Но как всегда ожидайте, в дальнейшем будет лучше....
А чем плох старый DHCP?Ах да, просто читаемая конфигурация, и отсутствие необходимости городить SQL-сервер..
Короче - провайдерам, для остальных - нафиг не нужно.
> Короче - провайдерам, для остальных - нафиг не нужно.Верно. Для домашнего применения вполне хватает Dnsmasq.
У вас фобия SQL-сервера? Ну держите данные в CSV, нет проблем.