Press "Enter" to skip to content

Archiv pro štítek: databaze

Antivirus – zlo pro úložné systémy

Část mé pracovní náplně je i řešení zákaznických problémů, se kterými si náš support již neví rady. Nejčastějšími problémy, se kterými se potýkám, jsou způsobené právě tím, že zákazníci provozují náš úložný systém na prostředí spolu s antivirem, mnohdy i backupem. Ačkoliv náš admin guide docela důrazně tento typ deploymentu nedoporučuje, je velké množství zákazníků, kteří to přesto dělají a jsou přesvědčení, že neudělali absolutně nic špatně.

Setkávám se s chybami typu:

  • Chyba zápisu
  • Chyba mazání
  • Hromada .DELETEPENDING souborů (mnohdy bez chyby)
  • Nenávratně poškozená data / soubory
  • Různé windows-ntfs systémové chyby
  • Nedostatečný výkon

Proč je antivirus/backup takové peklo?

Smysl antiviru je ochrana uživatele před potenciálními útoky, viry, apod. K tomu, aby dokázal opravdu efektivně uživatele chránit, musí mít přehled o každém dění v definovaném prostředí – příchozí/odchozí data, sledovat aktivitu místních procesů, kontrolovat především data, do kterých se příliž často zapisuje…

Backup zase potřebuje mít přehled o změnách v datech, tzn. pravidelně skenovat data, aby mohl při výpadku co nejefektivněji ochránit uživatele před ztrátou dat.

Úložný/databázový systém potřebuje co nejrychleji dokončovat IO operace – rychle se zbavit dávky dat kterou dostal k uložení, rychle poskytnout uživateli uložená data.

Zde vzniká konflikt zájmů.

Teoretická modelová situace 0: 

Databázový systém si chce otevřít soubor, ale dostane od file systému chybu, že soubor má otevřený jiný program – antivirus. Databázový systém tuto chybu neočekává – kdo by měl přece otevřené soubory, které používá jenom on?

Teoretická modelová situace 1:

Databázový systém si vytvořil soubor A, do kterého průběžně hrne nemalé množství dat. Velikost souboru A jednak rychle narůstá, ale také se neustále mění. Toto chování je pro většinu antivirů jako pěst na oko – hned tam musí strčit svůj nos a zkontrolovat, co se děje. Protože antivirus pracuje převážně na jiné úrovni než běžné programy, jeho priorita je vyšší. Protože se file systém snaží zachovat nějakou integritu dat, v lepším případě nedovolí oboum programům zároveň zapisovat a číst z jednoho zdroje. Ale protože antivirus má vyšší prioritu, kontroluje každý zápis do souboru A – dojde k razantnímu zpomalení kvůli čtení a analýzám antiviru. „Dobrý“ antivirus řeší i kontext, takže ho nezajímá jenom změna souboru (neukládá si žádnou historii), ale skenuje celý soubor. Databázový systém samozřejmě nechápe co se děje, a pokud dojde k jeho zahlcení, obvykle se z toho odporoučí. Soubor se nekorektně uzavře, zapomenou se data, apod.

Teoretická modelová situace 2:

Databázový systém začíná svou každodenní údržbu. Při takové údržbě jednak dochází k nějakým post-procesingovým záležitostem, ale taky třeba k mazání starých dat. Dojde k označení souborů B že je nutno jej smazat. Tato operace je uložena někde hluboko a aby se databázový systém nezdržovat, pokračuje si vesele dál – informaci o mazání předal jiné části. Antivirus si opět všimne nějaké větší aktivity a začne do všeho strkat nos. Tato aplikace si otevřela soubor B – podíváme se, jestli náhodou není podezřelý, soubor si otevře. Protože mazání souboru je věc, kterou obvykle činí file systém na pozadí. Dokud existuje někdo, kdo má soubor otevřený, soubor se nesmaže. Nyní mám několik teorií, co se stává:

  • operace mazání má timeout,
  • antivirus / backup špatně zavírá soubor – blokuje mazání

Teoretická modelová situace 3: 

Databázový systém má soubor C, kde potřebuje provést změnu. Protože antivirus detekuje otevření souboru do kterého se často přistupuje, začne provádět jeho analýzu. Nad velkým množství dat jsou často zápisy do souborů prováděny postupně. Každá potenciální změna způsobí, že se antivirus rozhodne dělat hloubkovou analýzu. Nejhorší to je u dočasných (temporary) souborů, které se často vytvářejí pro různé výpočty nad daty. A právě v temporary souborech se často ukrývají největší záškodníci, takže antivirus je samozřejmě nenechá být.

Proč vyloučení (exclude) nestačí

Vyloučení složek a souborů, které nechcete zatěžovat scany antiviru, je sice super věc pro statická data, avšak aktivní monitorování chování běžících procesů nevypnete. Nemluvě o tom, že pokud chce být antivirus „spolehlivý“, tak se tomuto vyloučení nedá na 100% věřit, pokud je tam častá aktivita. Hodně uživatelů nechává antivirus alespoň nad sytémovou Temp složkou, bohužel přesně jak název složky napovídá, je tam mnohdy hodně dočasných souborů a právě k dočasným souborům je mnohdy potřeba přistupovat rychle a často.

Pokud vypnete i aktivní monitorování, zůstává otázkou, na co vám vlastně ten antivirus je. Stejně nemáte pod kontrolou velkou část jeho činností – to je paradoxně to, co činí antivirus spolehlivým.

Pokud potřebujete mít zabezpečený databázový systém, nepotřebujete k tomu antivirus. Existují techniky, při kterých prostředí s databází oddělíte – zakážete všechno kromě databázové komunikace.

Opět jsem si rozšířila obzory…

Do předmětu PDB (pokročilé databáze) jsme s přítelem dělali celý http server v Javě, který komunikoval s Oracle databází. Do těď jsem se úspěšně Javě vyhýbala. V naději, že si Java se školní databází pokecá lépe než C#, ve kterém jsem chtěla vyvíjet původně, jsem na tu Javu přistoupila.

Ehm… Trochu (hodně) jsem se pletla.

Jestliže jsem si naivně myslela, že Java není tak strašná a že prostředí na komunikaci s databází bude minimálně tak přívětivé, jako je v Entity Framework… mno byla jsem úplně vedle. Ne, jediný rozdíl oproti potenciální implementace v C# byl akorát ve způsobu pracování Orácle SDO_GEOMETRY, jehož obdova v Javě je JGeometry. Tento typ se vůbec nemusí nijak převádět při komunikaci s databází.

Proč jsem tedy vlastně opustila od možnosti programovat to v C#? Bylo to mé zjištění, že ODP.NET (Oracle Data Provider, který funguje i s Entity Framework) nepodporuje SDO_GEOMETRY ani multimediální typy specifické pro Oracle, a bohužel celý projekt byl přesně o užívání těcho typů a SQL funkcí nad nimi. Jediný způsob (o kterém mi řekl až náš cvičící, kterému jsem psala nešťastný email), byl pomocí WKT (Well-known text).

V naději, že se vyhnu tomuto micromanagementu jsem přecházela do Javy, kde jsem se tomu stejně nevyhla. Protože to co C# dnes má obsaženo ve svých standardních knihovnách, Java jednoduše nemá. Běžné konverze mezi podobnými typy? Statické třídy i s kontrolou překladače? Typy jako Pair, Triplet, nebo Tuple? Nějaké dodržování standardu při pojmenovávání method? Ručnímu, nebo aspoň methodou generovanému SQL jsem se stejně nevyhla (Entity Framework a LINQ většinu téhle komunikace pro programátora příjemně zaobalí do líbivého a srozumitelného kédu) a práce s návratovou hodnotou z databáze je něco naprosto děsného. ResultSet má kurzor, vůbec se nedá mapovat na nějaký smysluplný senzam objektů se kterým by se dalo nějak rozumě pracovat. Teda pokud si to člověk neudělá všechno ručně, že.

Připadalo nám, že jsme se vrátili tak trochu zpět k C, ale pořád nám zůstal ten divný pocit objektovosti. Ani s C++ se to nedá srovnat, protože pokud používáte boost, hodně věcí už ani tam nemusíte řešit. Nejvíc zhrozená jsem asi byla ze způsovu, jakým fungují interface a abstraktní třídy. Nemluvě o šílené a bídné podpoře komunikace s Oracle databází, kterou jsme si stejně museli implementovat sami.

Java – Zpátky do jeskyní. Prý se někde na fórech říká, že Java je zombie jazyk. Mno, o C# se toho říká taky hodně… Ale dokud to bude Microsoft tlačit tak jak to tlačí, myslím, že má rozhodně mnohem větší budoucnost.

Takže jsem si zaprogramovala v Javě, zanadávala, vrátím se zpět k oblívenému C# v naději, že Javu už nikdy neuvidím. A na závěr si dovolím malý citát.

Java je dobrá jen na to, aby ji někdo vzal, pochopil, a přepsal do C#.