squid cache

 Konfigurisanje veličine keša (cache) u Squid proxy serveru uključuje postavljanje parametara kao što su cache_dir, cache_mem, i maximum_object_size kako bi se upravljalo prostorom na disku i RAM-u koji će se koristiti za keširanje web sadržaja. Evo koraka za konfigurisanje veličine keša u Squid proxy serveru:

Konfigurisanje cache_dir za diskovni keš:

Koristite cache_dir opciju kako biste postavili lokaciju i parametre za fizičko skladištenje keširanih objekata na disku. Ovaj korak omogućava Squid-u da čuva keširane resurse na disku.

Primer konfiguracije za cache_dir:

cache_dir aufs /putanja/do/keša 10000 16 256

/putanja/do/keša je putanja na disku gde će keširani sadržaji biti smešteni.

10000 je ukupan dostupan prostor u megabajtima za keširanje.

16 je broj poddirektorijuma za keširanje (ovisno o tipu keš sistema).

256 je maksimalna veličina objekta u kilobajtima.

Konfigurisanje cache_mem za keširanje u RAM-u:

Koristite cache_mem opciju kako biste postavili koliko RAM-a Squid može koristiti za keširanje u memoriji. Ovo omogućava brže keširanje za često korišćene objekte.

Primer konfiguracije za cache_mem:

cache_mem 512 MB

Ovde se postavlja da Squid može koristiti 512 megabajta RAM-a za keširanje u memoriji.

Konfigurisanje maximum_object_size:

Upotrebite maximum_object_size kako biste postavili maksimalnu veličinu objekta koji će biti keširan na disku. Ovo omogućava kontrolu veličine keširanih objekata.

Primer konfiguracije za maximum_object_size:

maximum_object_size 10 MB

Ovom konfiguracijom Squid će odbaciti keširane objekte koji premašuju 10 megabajta.

Restartovanje Squid-a:

Nakon što ste konfigurisali veličinu keša, sačuvajte konfiguracioni fajl i ponovo pokrenite Squid kako biste primenili promene.

Prilagodite vrednosti cache_dir, cache_mem i maximum_object_size u skladu sa raspoloživim resursima na serveru i specifičnim zahtevima vaše mreže kako biste postigli optimalnu konfiguraciju keša za vaš Squid proxy server.

squid refresh_pattern

refresh_pattern je ključna komponenta u konfiguraciji Squid proxy servera koja se koristi za upravljanje vremenom zadržavanja (cache) web resursa i načinom na koji se osvježavaju, tj. obnavljaju. Pomoću refresh_pattern možete kontrolisati koliko dugo će Squid čuvati kopije web stranica i kako će ih ažurirati ili osvježiti iz izvornog izvora (web servera).

Sintaksa refresh_pattern je obično sledeća:

refresh_pattern REGEX min percent max [options]

Evo šta ovi parametri znače:

REGEX: Ovo je regularni izraz (regular expression) koji se koristi za određivanje koje URL-ove ili resurse treba tretirati određenim vremenom osvježavanja. Na primjer, možete koristiti \.jpg$ kako biste odredili sve slike u JPG formatu.

min: Minimalno vreme (u minutima) koje Squid čuva kopiju resursa u kešu pre nego što se osvježi.

percent: Ovaj parametar određuje koliko će vremena od minimalnog vremena osvježenja (min) biti dodato kako bi se dobilo vreme osvježenja. Na primer, ako postavite percent na 50, to znači da će se vreme osvježenja računati kao 150% od minimalnog vremena.

max: Maksimalno vreme (u minutima) koje Squid može čuvati kopiju resursa u kešu pre nego što se mora osvježiti.

options (opcionalno): Dodatne opcije koje možete koristiti da biste prilagodili ponašanje refresh_pattern. Na primer, možete koristiti "ignore-reload" kako biste ignorisali zahtjeve za osvježavanje generisane od strane korisnika koji pritisnu "Refresh" u svom web pregledaču.

Primer upotrebe refresh_pattern može izgledati ovako:

refresh_pattern ^ftp:           1440    20%     10080

refresh_pattern -i \.(gif|jpg|png)$  10080  90%  43200 ignore-no-store override-expire override-lastmod ignore-reload

Ovaj primer kaže Squid-u da čuva FTP resurse 1440 minuta pre nego što razmotri osvježenje, a web slike u formatima GIF, JPG i PNG 10080 minuta pre nego što se osvježe. Takođe su navedene neke dodatne opcije za obradu ovih resursa.

Kako se osvežavaju resursi?

Squid proxy server osvežava (refresh) svoj keš tako što proverava vreme zadržavanja (refresh_pattern) za svaki keširani resurs i odlučuje kada treba da ažurira ili ponovo preuzme taj resurs sa izvornog servera. Proces osvežavanja u Squid-u ima sledeće karakteristike:

Provera vremena zadržavanja: Squid redovno proverava vreme zadržavanja koje je konfigurisano putem refresh_pattern za svaki keširani resurs. Ovo se radi kako bi se utvrdilo kada je resurs treba ažurirati.

Minimalno i maksimalno vreme zadržavanja: Squid koristi minimalno i maksimalno vreme zadržavanja (navedeno u refresh_pattern) kao smernice za odlučivanje kada ažurirati resurs. Minimalno vreme predstavlja minimalno vreme koje resurs mora biti u kešu pre nego što se osveži, dok maksimalno vreme ograničava koliko dugo resurs može ostati u kešu.

Ažuriranje resursa: Kada prođe minimalno vreme zadržavanja, Squid će proveriti da li je resurs istekao ili je bliži isteku od maksimalnog vremena zadržavanja. Ako je resurs istekao ili se približava isteku, Squid će ga smatrati "zastarelim" i zatražiti novo ažuriranje tog resursa sa izvornog servera.

Zahtev serveru: Squid šalje HTTP zahtev izvornom serveru kako bi osvežio zastareli resurs. Ovaj zahtev može sadržavati uslove kao što su "If-Modified-Since" kako bi se izbeglo nepotrebno ažuriranje ako se resurs nije promenio od poslednjeg keširanja.

Odgovor od izvornog servera: Izvorni server vraća odgovor Squid-u, koji sadrži ažurirani resurs ili informaciju da resurs nije promenjen (HTTP statusni kod 304 - Not Modified).

Ažuriranje keša: Ako je izvorni server poslao ažurirani resurs, Squid će ažurirati keširanu kopiju tog resursa sa novim podacima. Ako je izvorni server vratio HTTP 304 odgovor, Squid će zadržati postojeći keširani resurs i označiti ga kao važeći za buduće zahteve.

Ovaj proces osvežavanja omogućava Squid-u da održava aktuelne resurse u kešu, osigurava da se keširani sadržaj ne zastareva i da se ažurira prema zadatim pravilima konfiguracije. Kroz konfiguraciju refresh_pattern, administrator Squid proxy servera može prilagoditi kako se različiti tipovi resursa i URL-ova tretiraju u smislu osvežavanja i zadržavanja u kešu.

OPTIONS

Opcije (options) u konfiguraciji refresh_pattern u Squid proxy serveru omogućavaju dodatne prilagodbe za to kako se Squid ponaša prilikom osvežavanja (refreshing) keširanih resursa. Evo nekoliko čestih opcija koje se mogu koristiti:

ignore-reload: Ova opcija govori Squid-u da ignorira osvežavanje keširanog resursa ako korisnik pritisne dugme "Refresh" u svom web pregledaču. Ovo je korisno kada želite da korisnicima omogućite da ručno osveže stranicu, ali ne želite da Squid automatski osvežava resurse nakon korisničkog zahteva za osvežavanje.

ignore-no-store: Kada se ova opcija koristi, Squid će osvežiti resurse čak i ako je izvorni server poslao HTTP zaglavlje "Cache-Control: no-store" koje zabranjuje keširanje resursa. Ovo može biti korisno ako želite da Squid ignoriše takva HTTP zaglavlja i kešira resurse bez obzira na njihove politike o keširanju.

override-expire: Ova opcija omogućava Squid-u da ignoriše vreme isteka koje je postavio izvorni server i da osveži resurse prema refresh_pattern konfiguraciji. To znači da Squid neće čekati da resurs istekne pre nego što ga ažurira, već će se osvežiti prema svojim pravilima.

override-lastmod: Kada se ova opcija koristi, Squid će ignorisati HTTP zaglavlje "Last-Modified" koje izvorni server šalje za resurs. To znači da Squid neće koristiti "Last-Modified" za određivanje kada je resurs osvežen, već će se osvežavati prema refresh_pattern konfiguraciji.

ignore-must-revalidate: Ova opcija se koristi da bi Squid ignorisao HTTP zaglavlje "must-revalidate" koje može biti poslato od strane izvornog servera. "must-revalidate" zahteva da se svaki zahtjev za resursom pošalje iznova iz izvornog servera, ali korišćenjem ove opcije, Squid će ga ignorisati.

Squid proxy

Squid forward all requests to another proxy

cache_peer ipofparentproxy parent <port> 0 no-query default

#cache_peer_access ipofparentproxy allow !localnet

acl all src 0.0.0.0/0.0.0.0
http_access allow all

#never_direct deny noanotherproxyservers

never_direct allow all

#dns_nameservers ipofdnsa, ipofdnsb

Parameters

never_direct allow all 

By default squid always contacts the origin server to satisfy https requests

squid daemon know about a parent cache and squid can not connect directly to origin servers 

cache_peer_access peername allow|deny [!]ACLname

The cache_peer_access rules determine which requests Squid will forward to a particular neighbor. If a particular request is denied by a cache_peer_access list, Squid doesn’t forward the request to that neighbor. 

cache_peer_domain peer-cache.otherdomain.example !.mydomain.example

This tag is used to communicate with different caches depending on the domain that the request is destined for. To ensure that you don't query another cache server for your local domain, you can use the following config line:

refresh_pattern [-i] regexp min percent max [options]

refresh_pattern -i .gif$ 1440 20% 10080.

It helps Squid decide whether or not a given request can be a cache hit or must be treated as a miss.

refresh_pattern -i .gif$ 1440 20% 10080.

It helps Squid decide whether or not a given request can be a cache hit or must be treated as a miss.

Sinhrona replikacija

 Sinhrona replikacija je proces automatskog kopiranja podataka u realnom vremenu sa primarne lokacije na sekundarnu lokaciju. To znači da se promene koje se dese na primarnoj lokaciji automatski prenose na sekundarnu lokaciju, što rezultira u tome da su podaci na obe lokacije uvek identični i ažurni.

Sinhrona replikacija se najčešće koristi u sistemima za upravljanje bazama podataka i sistemima za upravljanje pohranom podataka koji zahtevaju visok nivo raspoloživosti podataka i minimalno vreme zastoja u slučaju neplaniranih događaja. Na primer, u slučaju da se dogodi kvar na primarnoj lokaciji, sinhrona replikacija omogućava da se sekundarna lokacija odmah aktivira i preuzme rad bez gubitka podataka.

Prednosti sinhronog replikacije su što omogućava visok nivo raspoloživosti podataka, minimizuje rizik od gubitka podataka, i smanjuje vreme neaktivnosti sistema u slučaju neplaniranih događaja. Međutim, sinhrona replikacija može imati uticaj na performanse sistema, jer svaka promena koja se desi na primarnoj lokaciji mora biti preneta i na sekundarnu lokaciju u realnom vremenu. Takođe, sinhrona replikacija je skuplja u odnosu na asinhronu replikaciju zbog veće potrebe za širokopojasnom mrežnom vezom i hardverskim resursima.

Asinhrona replikacija

 Asinhrona replikacija je vrsta replikacije podataka u kojoj se podaci kopiraju na drugu lokaciju u nekom vremenskom intervalu. To znači da se podaci ne prenose u realnom vremenu, već se šalju u određenim intervalima, što može dovesti do toga da kopija podataka na drugoj lokaciji nije u potpunosti ažurna.

Asinhrona replikacija se često koristi u sistemima za upravljanje bazama podataka i sistemima za upravljanje pohranom podataka, jer je efikasan način da se obezbedi visok stepen raspoloživosti podataka sa relativno malim uticajem na performanse sistema. Međutim, postoje neka ograničenja u korišćenju asinhrone replikacije, uključujući:

• Mogućnost gubitka podataka u slučaju neplaniranih događaja koji se dogode pre slanja podataka na drugu lokaciju.
• Mogućnost da podaci na primarnoj lokaciji ne budu u potpunosti sinhronizovani sa kopijom na drugoj lokaciji.
• Potreba za dodatnim mehanizmima zaštite podataka, kao što su backup i druge strategije za zaštitu podataka.

Zbog ovih ograničenja, asinhrona replikacija se obično koristi zajedno sa drugim metodama zaštite podataka, kao što su redovni backup-i i sinhrona replikacija.

Repliciranje podataka

 Repliciranje podataka je proces stvaranja i održavanja identičnih kopija podataka na dva ili više različitih fizičkih lokacija. Ovaj proces se obično koristi za poboljšanje raspoloživosti podataka i smanjenje rizika od gubitka podataka u slučaju kvara sistema ili drugih neplaniranih događaja.

Postoje različite vrste replikacije podataka, uključujući:

• Lokalna replikacija - replikacija podataka unutar istog data centra, što omogućava brz pristup podacima i smanjuje vreme oporavka u slučaju neplaniranih događaja.
• Udvostručenje - replikacija podataka na drugi geografski udaljeni data centar, što omogućava visok nivo raspoloživosti podataka u slučaju prirodnih katastrofa, kvarova mreže i drugih sličnih događaja.
• Repliciranje na nivou bloka - replikacija podataka na nivou bloka, što omogućava brzu sinhronizaciju podataka i smanjenje vremena oporavka.
• Repliciranje na nivou datoteka - replikacija podataka na nivou datoteka, što omogućava fleksibilnost u izboru podataka koji će biti replikovani i manje opterećenje mreže.

Repliciranje podataka se često koristi u sistemima za upravljanje bazama podataka, kao i u sistemima za upravljanje pohranom podataka u oblaku. Međutim, važno je naglasiti da replikacija podataka nije zamena za backup, jer može doći do grešaka u replikaciji koje mogu uzrokovati gubitak podataka. Zato se preporučuje korišćenje replikacije podataka zajedno sa redovnim backup-om.

Continuous Data Protection

 Continuous Data Protection (CDP) je tehnologija zaštite podataka koja omogućava neprekidno snimanje i arhiviranje podataka u realnom vremenu. Umesto tradicionalnog periodičnog backup-a koji se obično izvodi jednom dnevno ili nedeljno, CDP konstantno snima promene podataka i omogućava obnovu podataka u bilo kom trenutku.

CDP tehnologija obično koristi specijalizovani softver ili hardver za praćenje i beleženje promena podataka na sistemu. Ove promene se zapisuju u CDP sistem, koji se može nalaziti na lokalnom serveru, u oblaku ili na nekom drugom mestu, u zavisnosti od potreba korisnika. CDP sistem omogućava vraćanje podataka u bilo kojem trenutku u prošlosti, što može biti od koristi u slučaju otkrivanja problema sa podacima.

Prednosti CDP-a su brza obnova podataka i mogućnost povratka podataka u bilo kojem trenutku u prošlosti. Ovo je korisno u situacijama kada je potrebno povratiti podatke na specifičnom trenutku, na primer, ako je došlo do greške u sistemu ili do hakerskog napada. Međutim, CDP tehnologija može biti skuplja u odnosu na tradicionalne metode backup-a zbog većeg broja arhiviranih podataka i potrebnog hardverskog i softverskog sistema za snimanje i praćenje promena podataka u realnom vremenu.