PowerScale: Slik øker du syslog-eksportytelsen for PowerScale Isilon-revisjonsytelsen

Tilbakeloggingsloggen for syslog-revisjonseksporten blir aldri fanget opp. Det er ingen enkel måte å se dette på grunn av den distribuerte typen overvåkingsdatabaser og OneFS-arbeidsbelastning. 

En metode for å gjøre dette er:

1. Gjennomgå de nyeste tidsstempelene på mottatte revisjonssyslog-meldinger.
2. Hvis datoene for revisjonsposten ligger bak sanntidsdatoen din, ligger den bak.
3. Hvis postene hver dag ser ut til å være en konsekvent tidsperiode, eller noen ganger ligger bak og noen ganger blir fanget opp, betyr det at oppsettet av klyngen og syslog har relativ paritet. Dette er vanligvis akseptabelt. Hvor langt bak er akseptabelt, avhenger av miljøet.
4. Hvis ytelsen faller lenger og lenger bak hver dag og aldri fanger seg opp, kan det være nødvendig å redusere den lokale Isilon-side Audit-workloaden. 

Revisjon fungerer på en FIFO-kø (først inn, først ut) på alle noder.
Hvis overvåkingsdata eksporteres raskere enn de er inntatt, er køen oppdatert.

Hvis node nr. 1 inntar og registrerer 1000 overvåkingshendelser per sekund, men bare kan eksportere fra denne noden 500 hendelser per sekund, og denne frekvensen gjelder for 24x7x365, betyr det at for én enkelt Isilon-node:

• Etter 1 s er det en restanse på 500 elementer
• Etter 1 minutt, 30 000 elementer
• Etter 1 time, 1 800 000 elementer
• Etter 1 dag, 43 200 000 elementer

Hvis systemet selv om det er halvparten av timene på dagen, men systemet kan innta halvparten av hastigheten eller eksportere med dobbelt så høy hastighet, blir restansen halvert.

Når syslog-implementeringen brukes før 9.4, er rapporterte tilfeller av klienter med alvorlige revisjonsreserver relativt sjeldne.

Selv med CEE-alternativet, som er mer effektivt enn syslog før 9.4, er det noen ganger rapportert om restanse på grunn av den lokale revisjonsdesignen og de nyeste prisene.

Det kan være vanskelig å vite hvor mye volum det er før revisjonen kjører. Med den mer effektive CEE-en kan du også implementere flere CEE-målmaskiner, og deretter samarbeide med tredjepartsleverandøren som «samler inn» disse dataene for revisjonsregister.

Ekstra CEE-er gjør at Isilon-siden kan eksportere mer effektivt. Hver enkelt Isilon-node kan kobles til opptil tre (3) unike CEE-maskiner samtidig.

Syslog er forskjellig. Hvert definerte syslog-mål i revisjonsoppsettet mottar hver loggførte revisjonshendelse som eksporteres.
Forestill deg at én enkelt loggført revisjonshendelse sendes fra køen. Hvis det var én enkelt syslog-server for mål, sendte Isilon-noden med dette køelementet denne posten over UDP-port 514, på 1:1-basis, til den ene målsyslogen.
Hvis et annet syslog-mål ble lagt til, noe som gir to totale, må Isilon-noden i stedet sende det samme enkeltkøelementet til begge unike syslog-mål. Dette dobler effektivt noe av arbeidsbelastningen i Isilon-noden. Tre syslog-mål tredobler noe av arbeidet, og så videre.

Det finnes i tillegg ingen relevante kan tilpassede konfigurasjoner for pre-9.4 OneFS på syslog i henhold til revisjon.

Med CEE kan du redusere restansen ved å overvåke mindre og, eller legge til flere målbaserte CEE-er og mer tredjeparts leverandørkapasitet utover disse CEE-ene.

Med syslog kan du bare redusere restansen ved å overvåke mindre over tid.

Oppgrader til OneFS 9.4 eller nyere.

I optimale og kontrollerte laboratorietester har Syslog for revisjonseksport med OneFS 9.4-utgivelser vist ytelsesforbedringer på ~300 %.

Oppgradering til en versjon av OneFS på 9.4+, vil sannsynligvis gi ytelsesforbedringer i revisjonssyslog-eksportytelsen.

Ytelsen vil variere basert på miljø, implementering, design, nettverk, arbeidsstrømmer og menneskelig atferd som genererer revisjonsaktivitet. 
 

Hvis syslog-ytelsen for eksporter, selv på OneFS 9.4+ ikke kan overvinne en vedvarende eller uhåndterlig kø, flere uker etter oppgradering, kan du kontakte kundestøtte for gjennomgang.
Den eneste måten å redusere antall overvåkede hendelser per sekund og per node på, er å justere hvordan og hva som overvåkes.

Der syslog-eksporten «flyter» riktig fra Isilon-klyngen, er ytterligere optimalisering utenfor omfanget av Isilon-støtte:

• Se gjennom utformingen av hvordan du overvåker med Dells systemteknikere. Vurder hvordan sluttbrukerne (menneskelige eller automatiserte) kommer inn i klyngen i første omgang for å utføre revisjonsloggede aktiviteter.
• Balansere arbeidsflyter og volum av loggførte aktiviteter på tvers av alle Isilon-noder mer likt: Alle loggførte handlinger registreres bare for revisjon og eksporteres ut av noden som brukeren er koblet til.
• Hvis du har tjue noder i Isilon, men bare fem protokolltilkoblinger, vil 100 % av disse revisjonsaktivitetene bare forekomme på disse fem nodene.
• Vurder å gjennomgå hele implementeringen for å sikre at det totale volumet av alle protokollaktiviteter distribueres over så mange fysiske noder som mulig. Dette distribuerer den totale revisjonsarbeidsmengden over så mange noder som mulig.
• Vurder en CEE-basert løsning som et alternativ.
• Vurder å redusere volumet og omfanget av det som overvåkes. Ikke gå langt utover organisasjonsmessige eller forskriftsmessige krav. 
• Kontakt Dell systemteknikk for videre diskusjoner.