Takže v čem je tedy rozdíl mezi kupou různorodých počítačů (z nichž mají některé serverové desky a paměti) a gridem.
Jsem myslel, že v gridu bude minimálně nějaká SW vrstva (něco jako Java), která umožní rozdělit úlohy na všechny PC, a zajistí jistou jednotnost prostředí, ale ono to spíš vypadá, že jsou to jen "shluky" počítačových farem, které jsou seskupeny spíše formálně.
Je jediná výhoda v tom, že si člověk může požádat o výkon na jednom místě a nemusí prolézat různé formuláře (tedy výhoda administrační), a nebo existuje i nějaká jiná?
Takhle mi to připadá, že když si dám doma dohromady několik počítačů, tak si to můžu označit za grid. Jsem čekal aspoň nějakou mezivrstvu, aby člověk nemusel kompilovat aplikace pro každý typ HW, OS a SW...
Díky za reakci, tihle "žrouti" mě celkem zajímají :) (kde bychom byly bez nich, ani bych nevěděl, jestli bude zítra na horách sněžit).
Chtělo by to podrobnější článek. Mě osobně nezajímá jen HW, ale i SW, jak se jedna úloha rozdělí na takové mnoství rozdílných platforem (je možné jedním úkolem rozděleným na thready zatížit celý grid najednou?), jestli tam je nějaká vrstva, která zajišťuje kompatibilitu.
Taky by mě zajímalo zajištění proti výpadkům, co když vypadne CPU, jaké jsou strategie zálohování.
Jak se provádí kontrola výpočtů, jedna když nechám něco běžet na 1k procesorech... Je to čistě na aplikační vrstvě, aby si zkontrolovala správnost dat, a nebo se kontroluje HW i nějak interně a sám opravuje chyby a odstraňuje vadné bloky HW?
V principu je možné dobře napsanou aplikací využívat zároveň i stroje rozdílných platforem (existují komunikační knihovny, které to podporují), obvyklejší je ale využití podmnožiny strojů se stejnou architekturou, protože konverze dat mezi architekturami mohou brát část výkonu a při psaní aplikací je třeba s možnými rozdíly počítat (kromě konverzí binárních dat mohou přijít do cesty zvláštnosti různých operačních systémů, kompilátorů apod.).
Na zjevný výpadek procesorů za běhu aplikace upozorní aplikaci komunikační vrstva - část výpočetních procesů se přestane ozývat, jinak je to na aplikační vrstvě. Opravy malých chyb jsou u některého HW možné (ECC paměti, kontrolní kódy v síťových protokolech), ale obecně se toho u běžných PC serverů, které tvoří většinu HW zdrojů METACentra, bez spolupráce s aplikační vrstvou moc dělat nedá a výpadek je třeba řešit novým spuštěním aplikace (stroje, o kterých se ví, že mají HW problémy se zablokují v systému pro plánování úloh).