On January 23, 2021 10:06:19 AM GMT+02:00, Adrian Sevcenco <adrian.sevce...@cern.ch> wrote: >On 1/23/21 2:37 AM, wo...@prolinux.ro wrote: >> On January 23, 2021 1:22:36 AM GMT+02:00, Adrian Sevcenco >> <adrian.sevce...@cern.ch> wrote: >>> Salutare! Am o dilema existentiala: am un butoi mare si cel putin >>> momentan o tzeava ff mica. Momentan, framele de pauza sunt off si >>> pe deviceuri si pe noduri pentru ca am citit pe undeva ca trebuie >>> lasati algoritmii de congestie sa isi faca treaba, nu sa te pui in >>> calea fericirii lor. Problema e ca tzeava va fi intotdeauna ff mica >>> (pentru ca va dura o eternitate sa trecem noi la 100 sau Nx 100) >>> deci indiferent ca upgradam la 2x10 de la 10 simplu problema e >>> aceiasi: pa linga ca tot restul traficului (light, office) se >>> gatuie vad si cresteri de 20 de ori la rtt (la destinatii vecine de >>> 2ms se ajunge ls 40). >>> >>> So, cam ce ma sfatuiti? merita sa risc o saptamana de transpiratie >>> sa activez dc wide framele de pauza (mai ales pe switchuri)? >>> >>> Multumesc! Adrian >>> >>> Stiu ca ar fi cazul sa ma uit peste QoS :( .. la un moment dat o sa >>> ma uit, caut acum sa vad daca scap :D >Salut! > >> Pune mina si invata tc . E futere de utere in prima faza si cucuie + >> dragoste in gura de la colegii care se simt persecutati dar e solutia >> corecta, dpdv-ul meu >pai .. ce legatura are tc-ul?
tc= traffic control . Se aplica oriunde ai nevoie de categorisire si prioritizare. Exemplul tipic e ftp (care nu e interactiv) vs chestii time critical. Eu de pilda prioritizez traficul de voce (totul la noi e VoIP) astfel incit sa aiba jitter minim > problema nu e la hosturi ci mai sus unde >se aduna traficul in swithuri.. >mai ales ca nu e problema de colegi, am zis eu ceva de colegi ? >problema e traficul grid de >stocare > >mai ales ca nici acolo nu e in sine problema ci doar la switch-ul l3 de edge >... > >so, mai exact situatie e asa: >central e un dell de 25 gbps la care se conecteaza storage-urile si >compute-urile .. storage-urile duc fiecare pana in 1 Gib/s si marea >majoritate din trafic e consumat de compute-ul intern. > >dell-ul se conecteaza cu 10 gbps la switchul de edge (un hp 5800) > >dar, restul de trafic e din extern (vecinii nostrii de experiment si >platforma, cu care suntem federati ca si stocare) iar tzeava de 10 gbps se >satureaza (si sta saturata) rapid > >so.. unde intervine tc-ul in schema? Daca aproape tot traficul relevant prin edge e cel catre storage, mai mult decit separare in vlanuri (pe toate switchurile !) daca aplicatiile/utilizatorii se preteaza si ceva prioritizare intre ele (hence tc aka QOS) nu stiu ce poti face. Pari sa descrii una dintre problemele care se rezolva prin forta bruta aka furtun mai gros. Presupun ca nu aveti posibilitatea sa faceti un bonding intre switchuri, sa treceti la un n*10GB ? > >platforma e cam generic denumita, sunt ~10 institute prin zona, la noi >sigur nu ai prestat acum 25 de ani ca nu aveai la ce sa prestezi acum >25 >de ani :)))) Cu ISS am avut o colaborare. wolfy _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
