ot zlatozar(21-10-2006)
reiting (24)
[  dobre ]
[  zle ]
 Variant za otpechatvane
Reshih da napisha statiia za PF ama to kato gledam s kakva skorost se razvivata niama da stane skoro. Zatova shte opitam da si raziasnia HFCS planirovchika. SHTe poiasnia osnovnite neshta, optimizatsiiata i "hvatkite" sa si vashe delo.
Otkude idva imeto HFSC? Tova e sukrashtenie na Hierarchical Fair Service Curve Algorithm. Eto i kakva e ideiata. Dobre e planirovchika da se samonaglasia i da vzema rasheniia spored sluchaia - selfadopted.
V HFSC ima DVA planirovchika(packet schedularas). Purviia e garantiraniia ili t.n. realtime, a vtoriia linkshare. HFSC shte izbere avtomatichno, koi ot dvata shte izpolzva ako na mesta parametrite se prepokrivat. Parametrite, koito kontrolirat tezi dva planirovchika sa:
realtime - toi kontrolira minimalnata shirina (bandwidth), koiato se iziskva ot opashkata. Kogato ima vuzmozhnost HFSC predpochita tozi, toi e default. Goleminata mu shte narastva dokato se dostigne limita na kanala ili se dostigne upperlimit ogranichenieto. Ako niamame realtime planirovchik ili "interneta" ni e malko i ne mozhem da garantirame nuzhniia minimum, shte se izpolzva linkshare. Tozi parametur e optsionalen.
Oshte po nagledno:
if (there is an eligible packet)
/* real-time criteria */
send eligible packet with min. deadline d ;
else
/* link-sharing criteria */
send packet with min. virtual time v ;
linkshare - toi opredelia kolko da se vzeme trafika za tekushtata ot opashkata bashta (parent queue). Razpredelia proportsionalno interneta. Ako imame izlishuk toi shte se izpolzva spored dopulnitelnite parametri ili dokato se dostigne upperlimit (ako e upomenat). I tozi parametur e optsionalen.
Malko po osobeno e. Kudeto sa definirani realtime i linkshare i parametrite v tiah se prepokrivat shte se predpochete realtime. Realtime e planirovchika po podrazbirane. I oshte neshto, ako v definitsiiata na opashkata (a ne v altq) ne se izpolzva linkshare zadulzhitelno triabva da se napishe bandwidth! V protiven sluchai pfctl shte se oplache. Zapomnete go, makar mai se promeni tova v novite versii na pf.
Nadlezhno pokazvam kakvo sum vidial v koda:
ls - linkshare
rt - realtime
ul - upper limit
/* if link_share is not specified, use bandwidth */
if (opts->lssc_m2 == 0)
opts->lssc_m2 = pa->bandwidth;
if ((opts->rtsc_m1 > 0 && opts->rtsc_m2 == 0) ||
(opts->lssc_m1 > 0 && opts->lssc_m2 == 0) ||
(opts->ulsc_m1 > 0 && opts->ulsc_m2 == 0)) {
warnx("m2 is zero for %s", pa->qname);
return (-1);
}
Primer:
altq on $ext_if hfsc bandwidth 45Mb
queue{dns, ssh, www, mail, other}
queue dns bandwidth 10%
queue ssh bandwidth 10%
queue mail bandwidth 20%
queue www bandwidth 40%
queue other hfsc(default)
upperlimit - tova e maksimalnoto kolichestvo "internet", koeto niakoia ot opashkite mozhe da izpolzva. I oshte neshto, koeto se razbira ama az da si go kazha: Stoinostta na upperlimmit triabva da e po-goliama ot limitite postaveni v realtime i linkshare. Tozi parametur e optsionalen.
Nuzhdaem se i ot malko teoriia. Eto i neobhodimata portsiia.
Sled vseki edin ot tezi parametri ima chislo, koeto ukazva kakva chast ot internet potoka triabva da se zadeli ili ot slednite 3 chisla (m1 d m2). Kakvo zanachat tezi chisla
m1 - purvonachalnoto kolichestvo internet.
d - zabavianeto (time delay, in milliseconds)
m2 - korektsiia na kolichestvoto internet
Tezi parametri opredeliat taka narechenata "servizna kriva" (service curve). Tia mozhe da bude dva tipa:
izpuknala (convex) pri m1 > m2
vdlubnata (concave) pri m1
Interesen e sluchaia m1 = m2. V tozi sluchai niama da ima korektsii i vie prosto priniziavate HFSC do CBQ ;)
Zabelezhka: Osven tazi dinamika mozhete i da dobavite i prioriteti na paketite (PRIQ).
VAZHNO:
1) realtime parametrite ne mogat da budat po-golemi ot 75% ot tseliia ni internet (total interface bandwidth)
2) krivata na realtime triabva da e vinagi izpuknala (m1 > m2).
Da onagledim neshtata:
# PARENT QUEUE DEFINITION
altq on $ext_if hfsc bandwidth 45Mb
queue{dmznet, prvnet, others}
# CHILD QUEUE DEFINITIONS
# ako paketite se zadurzhat do 10 sek. shte vzeme 50% ili poveche
# ot tsialiia internet. Kogato paketite pristigat poveche i poveche i
# planirovchika gi zadurzha poveche ot 10 sek. shte se opita da se korigira
# i zavzeme 65% ot interneta.
queue dmznet hfsc(linkshare (50% 10000 65%))
# i tuk e sushtoto, samo che shte se korigira kum po-malko!
queue prvnet hfsc(linkshare (40% 5000 25%))
queue others hfsc(default)
Neka da poiasnim neshtata. Mozhe da razglezhdate opashkite kato skacheni sudove, ednoto e za smetka na drugoto. Zatova sumata ot parametrite ot edin vid ne triabva da nadvishavat kolichestvoto internet (total bandwith) kato default opashkata ne vliza v tiia smetki. Tezi stoinosti mogat da sa %, b, Kb, Mb, Gb.
Da napravim analiz. Da kazhem, che v DMZ zonata ima FTP survur i v edin moment pochva da bulva trafik i "trubata" ot 50% ne mozhe da smogne (bavi paketite poveche ot 10 sek.) zatova planirovchika ia razshiriava avtomatichno. Razshiriavaneto e za smetka obache na privnet. Zashto sum slozhil sum 5 sek? Rasuzhdavam taka, ako niakoe tipche trugne da svalia neshto shte zapulni "trubata" i az shte go rezna kato izrichno namalia kapatsieta. Vtoro, ako zabavianeto e poveche ot 5 sek. to niakude drugade(v sluchaia dmz zonata) stava neshto, triabva poveche internet. Hm, za optimizatsiiata se razbrahme ne moga da kazha tochno kakvo triabva da e zabavianeto (delay).
Zapameti. Gornata granitsa na razshiriavaneto mozhe da se ogranichi edinstveno ot upperlimit.
Neshtata stavat oshte po-interesni, kogato namesim i realtime. Kakto vi kazah mogat da budat definirani ednovremenno. HFSC avtomatichno shte izbere, koi shte svurshi po-dobra rabota. Mozhe da izberete da imat ednakvi parametri, mozhe i da izmislite neshto po-hitro. Derzaite, no ne zabraviaite, che serviznata kriva na realtime vinagi triabva da bude izpuknala (m1 > m2). I ot tuk i prostichkoto pravilo: ako iskate pri zabaviane da uvelichite kanala - linkshare, ako ne - realtime.
Primer:
# PARENT QUEUE DEFINITION
altq on $ext_if hfsc bandwidth 45Mb
queue{dmznet, prvnet, others}
# CHILD QUEUE DEFINITIONS
queue dmznet hfsc(linkshare (50% 10000 65%))
# HFSC shte izbere sam.
queue prvnet hfsc(realtime (40% 5000 25%) linkshare (40% 5000 25%))
queue others hfsc(default)
I ostana posledno smiataneto na kolichestvata internet. Sravnete slednite dva primera:
# CBQ
altq on $ext_if cbq bandwidth 20Mb queue{dmznet, prvnet, others}
# prvnet gets 8Mb
queue prvnet bandwidth 40% queue{host1, host2}
# host1 gets 4Mb
queue host1 bandwidth 50%
# host2 gets 4Mb
queue host2 bandwidth 50%
# HFSC
altq on $ext_if hfsc bandwidth 20Mb queue{dmznet, prvnet, others}
# prvnet gets 8Mb
queue prvnet hfsc(linkshare 40%) queue{host1, host2}
# host1 gets 4Mb
queue host1 hfsc(linkshare 20%)
# host2 gets 4Mb
queue host2 hfsc(linkshare 20%)
Kakvo se zabeliazva? CBQ razpredelia parametrite spriamo parent opashkata, a HFSC spriamo root! Mnogo chesto se greshi vnimavaite!
Iskam da spomena i edin drug parametur, koito chesto pipam qlimit. Toi opredelia kolko da e goliama opashkata i ot tam kolko gladko da se obrabotva. Po podrazbirane e 50 paketa. Predi da pravite radikalni promeni poigraite si s qlimit.
queue oRel bandwidth 128Kb qlimit 100 hfsc( linkshare 128Kb ) { oRelTCP, oRelUDP }
queue oRelTCP bandwidth 64Kb qlimit 60 hfsc( linkshare 64Kb default red )
queue oRelUDP bandwidth 64Kb qlimit 60 hfsc( linkshare 64Kb)
Kakvo da izpolzvame? Ako iskame da sortirame trafika po prioritet shte se vuzpolzvame ot PRIQ. Ako iskame da razpredelim neshtata "na kalpak" - CBQ. I nakraia ako iskame vsichko tova plyus razni drugi krasivi dobavki HFSC.
Ako i tova ne vi e dostatuchno vizhte v bloga mi http://zlatozar.blogspot.com
<< Programirane grafichen interfeis (GUI) s Lazarus i freepascal | Kraina tsel: FreeBSD >>
|
