- databázi
- Javu
- Middleware
- Vývoj
Podrobný popis všech tracků je k dispozici zde, registraci najdete tady.
čtvrtek 16. října 2014
Oracle Virtual Technology Summit 26. listopadu
Koncem listopadu bude probíhat zajímavý online seminář, sestávající z několika paralelních tracků, zaměřených na:
Podrobný popis všech tracků je k dispozici zde, registraci najdete tady.
Podrobný popis všech tracků je k dispozici zde, registraci najdete tady.
pátek 3. října 2014
Enterprise Scheduler Service (ESS)
Jak asi víte, koncem června uvedl Oracle na trh novou verzi balíku SOA Suite, konečně ve verzi 12c. Ta je technologicky postavena nad Weblogicem 12c, takže konečně po asi 5ti letech dochází ke sjednocení vývoje obou těchto platforem.
V rámci SOA Suite 12c se kromě produktů, které do SOA Suite patřily už v předchozích verzích, objevily i dvě nové, řekl bych velmi zajímavé komponenty: Managed File Transfer (MFT) a Enterprise Scheduler Service (ESS), na kterou se zaměřuje tento příspěvek. Jeho cílem je stručně a srozumitelně popsat hlavní vlastnosti a funkcionalitu ESS.
Každá větší společnost potřebuje ve svém IT prostředí spouštět opakovaně či ad-hoc velkou spoustu rozličných typů úloh (dále jobů). Mohou to být shell/OS scripty, uložené procedury, volání EJB atd. A právě tuto problematiku, ve které často panuje značný chaos, pomáhá řešit ESS.
ESS podporuje následující typy jobů: PLSQL, Java, EJB, spawned a samozřejmě i Web services. Vlastní typy jobů prozatím podporovány nejsou.
Řeší také vzájemné závislosti a konflikty mezi joby.
Monitorování, konfigurace a troubleshooting ESS jsou prováděny pomocí nástroje Enterprise Manager (EM), podporován je i WLST.
Scheduling jobů je definován v souladu s IETF standardem RFC 2445 (iCal), který slouží k definici opakovaně spouštěných úloh. Je např. možné rozdělit jednu velkou úlohu na více podúloh, např. zpracování výplat pro zaměstnance velké firmy provádět sadou podúloh, jednu pro každé písmeno abecedy (dle jejich přijmení). Tato množina je pak označována termínem "jobset". Jobsety mohou být vnořené a joby v nich mohou být prováděny buď sekvenčně, nebo paralelně.
Vytvoření jobu probíhá následujícím způsobem:
V praxi to pak v Enterprise Manageru vypadá takto:
ESS pracuje s následujícími objekty:
WorkAssignment mapuje sadu zdrojů(WorkShift) na joby, vybrané pomocí kriterií uložených ve Specialization.
RequestProcessor je namapován na server a zajišťuje spouštění k němu přiřazených WorkAssignmentů.
WorkShift objekt určuje zdroje (thready a throttling), které pak přiřazuje konkrétním jobům.
Specialization obsahuje kriteria jobu: uživatel, produkt, kategorie, job, jobset.
Schedule je objekt, obsahující definici data, času a opakování. Je definována nezávisle na konkrétním jobu a k jobům/jobsetům je přiřazována až po jejich vytvoření.
Vztahy mezi těmito objekty zachycuje následující diagram:
Throttling (regulace zátěže): ESS umožňuje pro každý job nastavit omezení, jaký maximální počet instancí tohoto jobu může v čase běžet
Targeting: je možné říci, na jakém serveru a kdy má být daný job prováděn. Tedy např. servery X a Y budou provádět každých posledních 5 dní v kvartálu účetní joby apod. Tím je možné využít kapacit silnějších a výkonnějších serverů a směrovat na ně tuto zátěž.
ESS pracuje s následujícími uživatelskými rolemi:
ESS podporuje Weblogic a DB pouze ve verzi 12c.
V případě db je uložená PLSQL procedura volána db schedulerem. Výsledek jobu je možné vrátit pomocí AQ fronty. U Java jobů je vrácen výsledek pomocí Java Callback API, u webových služeb je možné použít async WS callback.
Následující stavový diagram zachycuje možné stavy a životní cyklus jobu:
Doporučené nasazení ESS je ve stejném clusteru jako SOA Suite, na který deployneme ESS runtime. Ten je tvořen .ear archivem, obsahujícím ESS Runtime plus pár sdílenými knihovnami.
Jobů může být prováděno obrovské množství. Pokud např. zakládají joby BPELovské procesy, typicky stovky nebo tisíce instancí těchto procesů během jednoho dne, nebo i hodiny, může být spouštěno a archivováno stejné mnpžství jobů. Proto je třeba historii již provedených jobů čistit, a právě k tomu slouží tzv. purge politika, kterou je možné realizovat dvěma způsoby:
Logical Purge - automaticky přiřazením Purge policy k jobu
Physical Purge - DBA ručně spouští uloženou PLSQL proceduru.
V rámci Purge policy je možné zadat různá kriteria pro čištění informací o jobech, které skončily úspěšně, s chybou apod.
Dokončení jobů: v případě chyby se ESS snaží job opravit (je-li to pro job povoleno) automaticky, a poté jej znovu spustit. Nejde-li job opravit automaticky (nebo to není povoleno), je upozorněn admin, který jej může opravit ručně.
Samozřejmě je možné v EM zobrazovat informace o jakémkoli job requestu:
V rámci SOA Suite 12c se kromě produktů, které do SOA Suite patřily už v předchozích verzích, objevily i dvě nové, řekl bych velmi zajímavé komponenty: Managed File Transfer (MFT) a Enterprise Scheduler Service (ESS), na kterou se zaměřuje tento příspěvek. Jeho cílem je stručně a srozumitelně popsat hlavní vlastnosti a funkcionalitu ESS.
Každá větší společnost potřebuje ve svém IT prostředí spouštět opakovaně či ad-hoc velkou spoustu rozličných typů úloh (dále jobů). Mohou to být shell/OS scripty, uložené procedury, volání EJB atd. A právě tuto problematiku, ve které často panuje značný chaos, pomáhá řešit ESS.
ESS podporuje následující typy jobů: PLSQL, Java, EJB, spawned a samozřejmě i Web services. Vlastní typy jobů prozatím podporovány nejsou.
Řeší také vzájemné závislosti a konflikty mezi joby.
Monitorování, konfigurace a troubleshooting ESS jsou prováděny pomocí nástroje Enterprise Manager (EM), podporován je i WLST.
Scheduling jobů je definován v souladu s IETF standardem RFC 2445 (iCal), který slouží k definici opakovaně spouštěných úloh. Je např. možné rozdělit jednu velkou úlohu na více podúloh, např. zpracování výplat pro zaměstnance velké firmy provádět sadou podúloh, jednu pro každé písmeno abecedy (dle jejich přijmení). Tato množina je pak označována termínem "jobset". Jobsety mohou být vnořené a joby v nich mohou být prováděny buď sekvenčně, nebo paralelně.
Vytvoření jobu probíhá následujícím způsobem:
V praxi to pak v Enterprise Manageru vypadá takto:
ESS pracuje s následujícími objekty:
WorkAssignment mapuje sadu zdrojů(WorkShift) na joby, vybrané pomocí kriterií uložených ve Specialization.
RequestProcessor je namapován na server a zajišťuje spouštění k němu přiřazených WorkAssignmentů.
WorkShift objekt určuje zdroje (thready a throttling), které pak přiřazuje konkrétním jobům.
Specialization obsahuje kriteria jobu: uživatel, produkt, kategorie, job, jobset.
Schedule je objekt, obsahující definici data, času a opakování. Je definována nezávisle na konkrétním jobu a k jobům/jobsetům je přiřazována až po jejich vytvoření.
Vztahy mezi těmito objekty zachycuje následující diagram:
Throttling (regulace zátěže): ESS umožňuje pro každý job nastavit omezení, jaký maximální počet instancí tohoto jobu může v čase běžet
Targeting: je možné říci, na jakém serveru a kdy má být daný job prováděn. Tedy např. servery X a Y budou provádět každých posledních 5 dní v kvartálu účetní joby apod. Tím je možné využít kapacit silnějších a výkonnějších serverů a směrovat na ně tuto zátěž.
ESS pracuje s následujícími uživatelskými rolemi:
- Job Developer - pomocí EM nebo JDeveloperu vytváří implementace a definice jobů a jobsetů.
- Business User - používán pouze ve Fusion aplikacích společnosti Oracle
- Administrator - pomocí EM definuje spouštění jobů, zabezpečení, spouští, monitoruje a zastavuje joby atd.
ESS podporuje Weblogic a DB pouze ve verzi 12c.
V případě db je uložená PLSQL procedura volána db schedulerem. Výsledek jobu je možné vrátit pomocí AQ fronty. U Java jobů je vrácen výsledek pomocí Java Callback API, u webových služeb je možné použít async WS callback.
Následující stavový diagram zachycuje možné stavy a životní cyklus jobu:
Doporučené nasazení ESS je ve stejném clusteru jako SOA Suite, na který deployneme ESS runtime. Ten je tvořen .ear archivem, obsahujícím ESS Runtime plus pár sdílenými knihovnami.
Správa ESS
Je prováděna výlučně pomocí nástroje Enterprise Manager (EM):Jobů může být prováděno obrovské množství. Pokud např. zakládají joby BPELovské procesy, typicky stovky nebo tisíce instancí těchto procesů během jednoho dne, nebo i hodiny, může být spouštěno a archivováno stejné mnpžství jobů. Proto je třeba historii již provedených jobů čistit, a právě k tomu slouží tzv. purge politika, kterou je možné realizovat dvěma způsoby:
Logical Purge - automaticky přiřazením Purge policy k jobu
Physical Purge - DBA ručně spouští uloženou PLSQL proceduru.
V rámci Purge policy je možné zadat různá kriteria pro čištění informací o jobech, které skončily úspěšně, s chybou apod.
Dokončení jobů: v případě chyby se ESS snaží job opravit (je-li to pro job povoleno) automaticky, a poté jej znovu spustit. Nejde-li job opravit automaticky (nebo to není povoleno), je upozorněn admin, který jej může opravit ručně.
Samozřejmě je možné v EM zobrazovat informace o jakémkoli job requestu:
Přihlásit se k odběru:
Příspěvky (Atom)