Prime
-
Всього повідомлень
732 -
Приєднався
-
Останній візит
-
Дней в лидерах
7
Тип контенту
Профили
Форум
Календарь
Сообщения додав Prime
-
-
незнал в какой альбом выкладывать
-
Только хотел написать по-поводу фейковой AS.
То, что доктор прописал в вашем случае.
-
Мов парость виноградної лози,
Плекайте Java пильно й ненастанно!
-
http://www.wireless.ua/photo/index.php?content%2FUKOS2012_n1%2F
можно переключиться в режим HTML
-
а команда такого плана будет работать? т.е. задача удалять старые архивы с ФТП автоматом...
нет, lftp просто сливает данные.
в частности команда mput
для задачи с удалением данных, лучше подойдет какой-то синхронизатор.
делать ftp велосипед не нужно, он должен получать массив данных с сервера, сравнивать с существующим, или же сравнивать даты создания файлов.
rsync например
-
include.lst:
/usr/local/billing
/var/www/html/billing
exclude.lst
/usr/local/billing/sql-cache/
-
репликация конечно классно, но в данном случае малоэффективна.
Репликация мастер-слейв хороша как раз для бекапа, можно смело лочить всю базу на слейве и не бояться, что что-то не успеет записаться.
ну в данном случае есть только NAS
-
конечно сильно.
данные же не потеряются.
При падении сервера с данными данные, как это ни странно, тоже не теряются. Лежат себе спокойно, ждут пока их поднимут. А при настроенной репликации - вообще песня, данные синхронизируются везде...
контроллеры на порядок проще резервировать.Накой городить огород из кучи машин (N серверов биллинга + M контроллеров облака), если достаточно простого кластера на 2 ноды, с pacemaker'ом в качестве CRM, мускулом в режиме мастер-мастер, и биллингом в виде мигрирующего ресурса? Разве что письками мериться, мол, "у меня биллинг в облаке личном живет"?
да, это уже почти стандарт дефакто СХД.
pacemaker хорош, бесспорно
просто со схемой Master-Master можно долго просидеть
тут же задача:
"сервер А после восстановления работы синхронизировал бы изменения согласно серверу Б, и наоборот."
-
конечно сильно.
данные же не потеряются.
контроллеры на порядок проще резервировать.
UPD:
вариант с Master - Slave очень даже ничего.
при условии, что со Slave не будет на Master ничего синхронизироваться.
Тупая репликация БД спасет
-
А после восстановления работы синхронизировал бы изменения согласно серверу Б, и наоборот.
возможно стоит посмотреть в сторону модного облачного хранения данных.
например VMWare vCloud или же проекта OpenStack:
в случае падения контроллера, просто не будет доступа к данным.
скриптами тут не обойтись.
размазывание данных вещь не сильно хитрая в отличии от общего проекта failover схемы.
в первую очередь следует вынести из сервера функции маршрутизации трафика.
-
насчет dl360
у него два режима работы кулеров: Low и Normal
частота вращения действительно меняется, но по общему уровню громкости разница очень слабая.
разбирал кулеры, они технологически так устроены.
т.е. вопрос решается заменой блока из по-моему 6 FANов, но заниматься колхозов с заменой штатных кулеров я бы не советовал.
другие HP сервер +- той же серии не шумят
причем один DL360 вообще не шумит, может серия такая была, хз.
-
для одного из тривиальных серверов я делал резервирование в 3 источника.
1.Local Storage
2.FTP
3.Amazon S3
Локальное хранилище хранит резервные копии за 31 день
FTP сервер хранит все резервные копии.
Amazon S3 хранит за 31 день истории.
Резервируются файлы и база данных биллинга.
директории файлов соответственно Include и exclude, чтобы избежать избыточности.
пример упростил, потому как у меня таблицы лочатся, на время выполнения дампа и конечно же не вся БД сливается.
репликация конечно классно, но в данном случае малоэффективна.
#!/bin/sh FILENAME=billing_files INCFILE="/etc/backup/include.lst" EXCFILE="/etc/backup/exclude.lst" NOW=`date "+%Y-%m-%d"` TMPNAME=/root/backup/billing/$FILENAME-$NOW.tar.bz2 tar -jc -T $INCFILE -X $EXCFILE --absolute-names -f $TMPNAME #create sql dump /usr/bin/mysqldump -uusernname -ppassword namedb | /usr/bin/bzip2 > /root/backup/billing/db_billing_$NOW.bz2 #rotate files cd /root/backup/billing; find . -name \*.tar.bz2 -mtime +31 -delete find . -name \*.bz2 -mtime +31 -delete #upload to FTP server /usr/bin/lftp -u billing_backup,billing_backuppassword 1.2.3.4 -e "mput $FILENAME-$NOW.tar.bz2;quit" /usr/bin/lftp -u billing_backup,billing_backuppassword 1.2.3.4 -e "mput db_billing_$NOW.bz2;quit" #Amazon /usr/local/bin//s3cmd-1.0.1/s3cmd --acl-private --bucket-location=EU --guess-mime-type --delete-removed sync /root/backup/billing s3://billing/
-
Наталья завидовала )
-
Пусть отключить arp протокол в ядре икаждого польователя вносит руками
-
ох жесть же будет....
-
а так, доступно два варианта:
1.работать напрямую с sql базы, данных, тем самым можно зад....чить запросами выборки каждого хомяка в большой сети.
2.формировать конфиги по триггеру измененных событий, ну тут проще, тем более реализация nomake есть для любых доп полей, чем создавать свой велосипед
когда-то давно была полемика насчет, что лучше.
ну впринципе можно еще сделать к 1 варианту режим кеширования и ограничения запросов, т.к. репликация нецелесообразна
-
Фактически нужно настроить только коммутатор и isc dhp сервер.
Дело в том, чтобы прйти к "попробовать", нужно это все сделать )
В разрезе данного вопроса это значит интегрировать в биллинг, настроить dhcp и свич.
Вам проще на первом этапе конфиг сделать руками, потестить в связке со свичем.
Дальше, если интересно начать придумывать велосипеды.
Втом числе как работа через sql, dhcp сервера, так и формирование конфига из доп полей.
Начните с малого...
Имеется в наличии
3 шт DES-3526, сервер на котором можно играться с софтом (сейчас там стоит Freebsd 8.2 и nodeny установленный по одному из видео)
Просто для меня это все ново и хотелось бы понять куда копать.
Статью про opt82 немного попытался осилить, понял что приходит от свича, но не до конца догнал как этот isc dhcp конфигурировать.
К примеру соберу все как тут
http://xgu.ru/wiki/Ф...йл:Dhcp_82.jpeg
на DHCP сервере стоит биллинг. что мне делать дальше? В конфиге для каждого коммутатор каждого порта прописывать свой класс или как?
И ещё насколько я понял DHCP сервер будет выписывать в какой-то лог с грубо говоря номер порта и МАС коммутатора, после чего биллинг должен распарсить этот лог и запомнить про пользователя на том порту и его ИП?
Тоесть биллинг работает по сути помнит что IP к примеру 192.168.1.10 находиться на порту коммутатора №15 с MAC 00:11:22:33:44:55:66:77, и при попытке попасть в интернеты он сверяет текущее положение дел с записанным, если совпадает - этот ИП пропускаем, если нет - блокируем. если ИП меняется - DHCP сервер сообщает об этом биллингу. Я прав?
на форуме nodeny были выложены реальные конфиги с работающих сетей с комментариями.
cat dhcp_opt82.txt
<file>/usr/local/etc/clients-static.conf</file> <template>1</template> <reload>/usr/local/etc/rc.d/isc-dhcpd restart</reload> # 10.5.226.0/24 Subnet subnet 10.5.226.0 netmask 255.255.255.0 { allow unknown-clients; option routers 10.5.226.1; <filtr net='10.5.226.0/24' dopdata-_use_option_82='1' state='on' dopdata-_mac_pc='^..:..:..:..:..:..$'> # <dopdata-_user_sw_num> - <dopdata-_user_sw_port> - <lat_login> - <ip> - <dopdata-_mac_pc> pool {range <ip>; allow members of \"match_swid_<dopdata-_user_sw_num>_port_<dopdata-_user_sw_port>\"; } </filtr> } subnet 10.5.227.0 netmask 255.255.255.224 { allow unknown-clients; option routers 10.5.227.1; <filtr net='10.5.227.0/27' dopdata-_use_option_82='1' state='on' dopdata-_mac_pc='^..:..:..:..:..:..$'> # <dopdata-_user_sw_num> - <dopdata-_user_sw_port> - <lat_login> - <ip> - <dopdata-_mac_pc> pool {range <ip>; allow members of \"match_swid_<dopdata-_user_sw_num>_port_<dopdata-_user_sw_port>\"; } </filtr> } -
адекватные цены , адекватные люди - там бродят. могут и на шару помочь. но ясное дело админить сеть за 10 бакс в месяц никто не будет . а договорится можно всегда.
тем, кто по-человечески спрашивал - никому не отказывали.
хотя совести нет, на шею садятся, думать не хотят
-
лучше бы на форуме nodeny спросили.
чтобы nodeny крутить вдоль и поперек - нужно его достаточно хорошо знать
-
местный, удаленный?
-
Фактически нужно настроить только коммутатор и isc dhp сервер.
Дело в том, чтобы прйти к "попробовать", нужно это все сделать )
В разрезе данного вопроса это значит интегрировать в биллинг, настроить dhcp и свич.
Вам проще на первом этапе конфиг сделать руками, потестить в связке со свичем.
Дальше, если интересно начать придумывать велосипеды.
Втом числе как работа через sql, dhcp сервера, так и формирование конфига из доп полей.
Начните с малого...
-
З.Ы. на форуме nodeny культурно послали нах, очень очень и очень тонко намекнули - нужны ответы - плати деньги
ну не совсем так, чтобы отказали.
дело в том, что все очень индивидуально получается, зоопарк оборудования разный, топология разная.
подстроить под вашу сеть будет стоить денег + вас же нужно научить как с этим работать, возможно перестроить девайсы.
-
можно по вендору
match if option dhcp-vendor-identifier = "<insert_vendor_class_id_here>";
обязательно клиент только отправлять send vendor-class-identifier
class "vendor-class" {
match if option dhcp-vendor-identifier = "<vendor-class-identifier>";
}
-
redir ему поможет
проблемы со скоростью на любом роутере
в Невеликі роутери. DSL, Wi-Fi, Ethernet
Опубліковано:
Проблемы с TTL или двойным NAT?