IBM Tivoli Access Manager fileÚvod IBM ®Tivoli Access Manager (Access Manager) je základní...

IBM Tivoli Access Manager

Průvodce kapacitním plánováním

GC09-3668-00

Poznámka:Než začnete používat uvedené informace a produkt, o který se opírají, přečtěte si informace uvedené v části “Poznámky” na stránce 19.

Druhé vydání (Březen 2002)

Toto vydání nahrazuje GC32-0811-00.

© Copyright International Business Machines Corporation 2001, 2002. Všechna práva vyhrazena.

ObsahÚvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vPro koho je určena tato kniha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vCo tato kniha obsahuje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vPublikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vSouvisející publikace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiOnline přístup k publikacím . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixObjednání publikací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixPoskytnutí zpětné vazby o publikacích . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Dostupnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xKontakt na zákaznickou podporu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xKonvence používané v této knize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Konvence typu písma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Plánování kapacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Proces plánování kapacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Vysvětlení možností topologie sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Servery v prostředí WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Možnosti topologie sítě WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Fyzické sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Identifikace transakcí serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Transakce v prostředí WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Definice požadavků na průchodnost transakcí serveru . . . . . . . . . . . . . . . . . . . . . . . 6Založení odhadů na empirických datech. . . . . . . . . . . . . . . . . . . . . . . . . . . 6Založení odhadů na registrovaných uživatelích. . . . . . . . . . . . . . . . . . . . . . . . . 6

Výběr hardwaru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Plánování paměti a místa na disku . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Získání měření/průchodnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Úprava typů transakcí tak, aby odpovídala zprávám o měření . . . . . . . . . . . . . . . . . . . . 9Škálování podle hardwarových rozdílů . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Škálování podle využití CPU, nižšího než 100% . . . . . . . . . . . . . . . . . . . . . . . . 10Škálování podle rozdílů ve velikostech stránek . . . . . . . . . . . . . . . . . . . . . . . . 10Škálování podle velikosti stránky a zabudovaných obrázků. . . . . . . . . . . . . . . . . . . . . 11Škálování podle rozdílů ve fyzických sítích . . . . . . . . . . . . . . . . . . . . . . . . . 11

Výpočet požadovaného počtu počítačů. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Zvyšování počtu počítačů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Vytvoření možností topologie sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Příklad plánování kapacit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Vysvětlení možností topologie sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Identifikace transakcí serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Definice požadavků na průchodnost transakcí serveru . . . . . . . . . . . . . . . . . . . . . . 14Výběr hardwaru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Získání měření/průchodnosti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Výpočet požadovaného počtu počítačů. . . . . . . . . . . . . . . . . . . . . . . . . . . 16Vytvoření možností topologie sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Poznámky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Ochranné známky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Rejstřík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

© Copyright IBM Corp. 2001, 2002 iii

iv Access Manager: Průvodce kapacitním plánováním

Úvod

IBM® Tivoli® Access Manager (Access Manager) je základní software, který je nezbytný,aby bylo možné pracovat s aplikacemi v produktové řadě Access Manager. Umožňujeintegraci aplikací Access Manager, které nabízí širokou paletu řešení autorizace a správy.Jsou-li prodány jako integrované řešení, mohou tyto produkty nabídnout řešení pro správuřízení přístupu, které centralizuje síť a bezpečnostní politiku pro e-business aplikace.

Poznámka: IBM Tivoli Access Manager je nové jméno dříve uvolněného softwaru zvanéhoTivoli SecureWay® Policy Director. Uživatelům, kteří dobře znali software adokumentaci produktu Tivoli SecureWay Policy Director, bychom chtěli dátvědět, že termín Management Server je nyní nahrazen termínem Policy Server.

Dokument Průvodce kapacitním plánováním produktu IBM Tivoli Access Manager pomáháprojektantům určit počet WebSEAL a LDAP serverů a webových serverů typu back-end,který je potřeba pro dosažení požadovaného vytížení.

Pro koho je určena tato knihaTento průvodce je určen pro systémové administrátory, odpovědné za instalaci a nasazeníproduktu Access Manager.

Čtenáři této knihy by měli být:v Systémoví administrátořiv Projektanti instalace, odpovědní za plánování nasazení produktu Access Manager a

WebSEAL.

Co tato kniha obsahujev Kapitola 1, “Plánování kapacit” na stránce 1

Obsahuje úvod do posouzení, se kterými je nutné se vypořádat v jednotlivých etapáchplánování nasazení produktové řady Access Manager. Předměty, o kterých je v této knizepojednáváno, jsou: topologie sítě, transakce serveru, požadavky na hardware, škálování apříklad plánování kapacit.

PublikaceTato část obsahuje seznam publikací v knihovně Access Manager a dalších souvisejícíchdokumentů. Dále popisuje, jak online přistupovat k Tivoli publikacím, jak objednávat Tivolipublikace a jak poskytovat komentář k Tivoli publikacím.

IBM Tivoli Access ManagerKnihovna Access Manager je rozdělena do následujících skupin:v Informace o vydánív Základní informacev Informace o WebSEALv Informace o zabezpečení Webuv Informace o odkazech pro vývojářev Doplňkové technické informace

© Copyright IBM Corp. 2001, 2002 v

Další zdroje informací o produktu Access Manager a souvisejících tématech najdete nanásledujících webových stránkách:

http://www.ibm.com/redbookshttps://www.tivoli.com/secure/support/documents/fieldguides

Informace o vydánív IBM Tivoli Access Manager for e-business: Čtěte jako první, GI11-0918

(am39_readme.pdf)Obsahuje informace pro instalaci a začátek práce s produktem Access Manager.

v IBM Tivoli Access Manager for e-business Release Notes, GI11-0919(am39_relnotes.pdf)Poskytuje nejnovější informace např. o omezeních softwaru, pomocných opraváchproblémů, nebo o aktualizacích dokumentace.

Základní informacev IBM Tivoli Access Manager Base Installation Guide, GC32-0844 (am39_install.pdf)

Vysvětluje, jak nainstalovat, nakonfigurovat a aktualizovat software produktu AccessManager, včetně rozhraní Web Portal Manager.

v Administrativní příručka IBM Tivoli Access Manager, GC23-4684 (am39_admin.pdf)Popisuje koncepty a procedury používání služeb produktu Access Manager. Poskytujeinstrukce pro provádění úloh z rozhraní Web Portal Manager a pro provádění úloh pomocípříkazu pdadmin.

v IBM Tivoli Access Manager Base for Linux on zSeries™ Installation Guide, GC23-4796(am39_zinstall.pdf)Vysvětluje, jak nainstalovat a nakonfigurovat Access Manager Base pro operační systémLinux na platformě zSeries.

Informace o WebSEALv IBM Tivoli Access Manager WebSEAL Installation Guide, GC32-0848

(amweb39_install.pdf)Poskytuje instrukce pro instalaci, konfiguraci a odstranění serveru WebSEAL a sady provývoj aplikací WebSEAL.

v Průvodce administrátora IBM Tivoli Access Manager WebSEAL, GC23-4682(amweb39_admin.pdf)Poskytuje podkladové materiály, administrativní procedury a informace o technickýchodkazech, nutné při používání WebSEAL ke správě zdrojů ve vaší zabezpečené webovédoméně.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference, GC23-4683(amweb39_devref.pdf)Poskytuje informace o administrativě a programování CDAS (Cross AuthenticationService), CDMF (Cross Mapping Framework) a modulu Odolnosti hesla.

v IBM Tivoli Access Manager WebSEAL for Linux on zSeries Installation Guide, GC23-4797(amweb39_zinstall.pdf)Poskytuje instrukce pro instalaci, konfiguraci a odstranění serveru WebSEAL a sady provývoj aplikací WebSEAL na operačním systému Linux na platformě zSeries.

Informace o zabezpečení Webuv Průvodce uživatele IBM Tivoli Access Manager for WebSphere Application Server,

GC09-3670 (amwas39_user.pdf)Poskytuje instrukce pro instalaci, odstranění a administrativu produktu Access Manager forIBM WebSphere® Application Server.

vi Access Manager: Průvodce kapacitním plánováním

v IBM Tivoli Access Manager for WebLogic Server User’s Guide, GC32-0851(amwls39_user.pdf)Poskytuje instrukce pro instalaci, odstranění a administrativu produktu Access Manager forBEA WebLogic Server.

v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide, GC23-4685(amedge39_user.pdf)Popisuje, jak nainstalovat, nakonfigurovat a administrovat plug-in pro IBM WebSphereEdge Server.

v Průvodce uživatele IBM Tivoli Access Manager Plug-in for Web Servers,GC23-4686(amws39_user.pdf)Poskytuje instrukce pro instalaci, administrativní procedury a informace o technickýchodkazech, týkající se zabezpečení vaší webové domény pomocí plug-in pro aplikacewebových serverů.

Reference pro vývojářev IBM Tivoli Access Manager Authorization C API Developer’s Reference, GC32-0849

(am39_authC_devref.pdf)Obsahuje referenční materiál, který popisuje, jak používat autorizační rozhraní C APIproduktu Access Manager a servisní plug-in rozhraní produktu Access Manager pro přidánízabezpečení Access Manager do aplikací.

v IBM Tivoli Access Manager Authorization Java Classes Developer’s Reference,GC23-4688 (am39_authJ_devref.pdf)Poskytuje referenční informace, jak pomocí implementace autorizačního rozhraní API vjazyce Java™ povolit, aby aplikace používala zabezpečení produktu Access Manager.

v IBM Tivoli Access Manager Administration C API Developer’s Reference,GC32-0843 (am39_adminC_devref.pdf)Poskytuje referenční informace, jak pomocí administrativního API povolit, aby aplikaceprováděla administrativní úlohy produktu Access Manager. Tento dokument popisujeimplementaci tohoto administrativního rozhraní API v jazyce C.

v IBM Tivoli Access Manager Administration Java Classes Developer’s Reference,SC32-0842 (am39_adminJ_devref.pdf)Poskytuje referenční informace, jak pomocí implementace administrativního rozhraní APIv jazyce Java povolit, aby aplikace prováděla administrativní úlohy produktu AccessManager.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference, GC23-4683(amweb39_devref.pdf)Poskytuje informace o administrativě a programování CDAS (Cross AuthenticationService), CDMF (Cross Mapping Framework) a modulu Odolnosti hesla.

Technické dodatkyv IBM Tivoli Access Manager Performance Tuning Guide, GC43-0846

(am39_perftune.pdf)Poskytuje informace o ladění výkonnosti pro prostředí, skládající se z produktů AccessManager a IBM SecureWay Directory, který je definován jako registr uživatelů.

v Průvodce kapacitním plánováním produktu IBM Tivoli Access Manager, GC32-0847(am39_capplan.pdf)Pomáhá projektantům určit počet WebSEAL, LDAP, a webových serverů typu back-end,který je potřeba pro dosažení požadovaného vytížení.

v IBM Tivoli Access Manager Error Message Reference, SC32-0845 (am39_error_ref.pdf)Obsahuje vysvětlení a doporučované akce pro zprávy, které vydává produkt AccessManager.

Úvod vii

Obsahem Tivoli Glossary jsou definice mnoha technických termínů, vztahujících se k Tivolisoftwaru. Tivoli Glossary je k dispozici pouze v angličtině na tomto webovém serveru:

http://www.tivoli.com/support/documents/glossary/termsm03.htm

Související publikaceTato sekce obsahuje seznam publikací, souvisejících s knihovnou Access Manager.

IBM DB2® Universal Database™

Produkt IBM DB2 Universal Database je vyžadován, pokud instalujete server IBMSecureWay Directory, nebo server z/OS™ a OS/390® SecureWay LDAP. Informace o DB2jsou k dispozici na tomto webovém serveru:

http://www.ibm.com/software/data/db2/

IBM SecureWay DirectoryIBM SecureWay Directory, verze 3.2.2, se dodává na CD-ROM IBM Tivoli Access ManagerBase pro vaši určitou platformu. Pokud hodláte nainstalovat IBM SecureWay Directory serverjako váš registr uživatelů, v adresáři /doc/Directory na CD-ROM IBM Tivoli AccessManager Base pro vaši určitou platformu jsou k dispozici následující dokumenty:v IBM SecureWay Directory Installation and Configuration Guide, SC32-0845

(aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf)Obsahuje informace o instalaci, konfiguraci a migraci komponent produktu IBMSecureWay Directory pro operační systémy AIX®, Linux, Solaris a Microsoft® Windows®.

v IBM SecureWay Directory Release Notes (relnote.pdf)Přidává dokumentaci produktu IBM SecureWay Directory, verze 3.2.2, a popisujekomponenty a funkce, které jsou vám k dispozici pro dané vydání.

v IBM SecureWay Directory Readme Addendum (addendum322.pdf)Obsahuje informace o změnách a opravách, které se objevily po přeložení dokumentaceproduktu IBM SecureWay Directory. Tento soubor je pouze v anglickém jazyce.

v IBM SecureWay Directory Server Readme (server.pdf)Obsahuje popis produktu IBM SecureWay Directory Server, verze 3.2.2.

v IBM SecureWay Directory Client Readme (client.pdf)Obsahuje popis produktu IBM SecureWay Directory Client SDK, verze 3.2.2. Tato sadapro vývoj softwaru (SDK - software development kit) obsahuje podporu vývoje LDAPaplikací.

v SSL Introduction and iKeyman User’s Guide (gskikm5c.pdf)Obsahuje informace pro administrátory sítě a systémového zabezpečení, kteří plánujípovolit SSL komunikaci ve své zabezpečené doméně Access Manager.

v IBM SecureWay Directory Configuration Schema (scparent.pdf)Popisuje DIT (directory information tree ) a atributy, které je možné použít při konfiguracisouboru slapd32.conf. Ve verzi 3.2 produktu IBM SecureWay Directory jsou nastaveníadresářů uložena ve formátu LDIF (LDAP Directory Interchange Format) v souboruslapd32.conf.

v IBM SecureWay Directory Tuning Guide (tuning.pdf)Obsahuje informace o ladění výkonnosti produktu IBM SecureWay Directory. Je-li topoužitelné, jsou dány ladící faktory pro velikosti adresářů v rozsahu od několika tisícůzáznamů po miliony záznamů.

Další informace o produktu IBM SecureWay Directory najdete na následujícím webovémserveru:

viii Access Manager: Průvodce kapacitním plánováním

http://www.software.ibm.com/network/directory/library/

IBM WebSphere Application ServerIBM WebSphere Application Server Standard Edition verze 4.0.2 je nainstalován s rozhranímWeb Portal Manager. Další informace o produktu IBM WebSphere Application Server najdetena následujícím webovém serveru:

http://www.ibm.com/software/webservers/appserv/infocenter.html

Online přístup k publikacímPublikace v produktových knihovnách jsou ve formátu PDF (Portable Document Format)součástí produktového CD-ROM. Chcete-li přistoupit k těmto publikacím prostřednictvímvašeho webového prohlížeče, otevřete soubor infocenter.html, který je v adresáři /doc naproduktovém CD-ROM.

Jakmile IBM publikuje aktualizovanou verzi jedné nebo více publikací, ať už online, nebo vtrvalém záznamu, umístí je na Tivoli Information Center. Tivoli Information Center obsahujenejnovější verze publikací v produktových knihovnách ve formátu PDF, HTML, nebo v obouformátech. Pro některé produkty jsou k dispozici také přeložené dokumenty.

Na Tivoli Information Center a další zdroje technických informací se dostanete z tohotowebového serveru:

http://www.tivoli.com/support/documents/

Informace jsou seřazeny podle produktů, včetně poznámek k jednotlivým vydáním, průvodcůinstalací, průvodců uživatele, průvodců administrátora a referencí pro vývojáře.

Poznámka: Pokud chcete vytisknout PDF dokumenty na jiný formát papíru, než je letter,zaškrtněte pole Fit to page v dialogu Print produktu Adobe Acrobat (ke kterémuse dostanete, pokud klepnete na File → Print), abyste zajistili, že celý rozsahstránky, formátované na velikost letter, bude vytisknuta na papír, kterýpoužíváte.

Objednání publikacíMnohé z Tivoli publikací si můžete online objednat na následujícím webovém serveru:

http://www.elink.ibmlink.ibm.com/public/applications/ publications/cgibin/pbi.cgi

Můžete si je také objednat telefonicky na těchto telefonních číslech:v Ve Spojených státech: 800-879-2755v V Kanadě: 800-426-4968v Seznam telefonních čísel pro ostatní země najdete na této webové stránce:

http://www.tivoli.com/inside/store/lit_order.html

Poskytnutí zpětné vazby o publikacíchVelmi se zajímáme o to, jaké máte zkušenosti s Tivoli produkty a dokumentací, a vítáme vašenávrhy pro další zlepšení. Pokud máte nějaké poznámky nebo návrhy k našim produktům adokumentaci, obraťte se na nás jedním z následujících způsobů:v Odešlete elektronickou zprávu na [email protected] Vyplňte dotazník pro zpětnou vazbu zákazníka na této webové stránce:

http://www.tivoli.com/support/survey/

Úvod ix

DostupnostFunkce dostupnosti pomáhají uživateli, který má tělesné postižení, jako např. sníženoupohyblivost nebo omezené viděni, úspěšně používat softwarové produkty.

Kontakt na zákaznickou podporuMáte-li problém s jakýmkoliv Tivoli produktem, můžete se obrátit na Zákaznickou podporuTivoli. Prohlédněte si příručku Tivoli Customer Support Handbook na následujícím webovémserveru:

http://www.tivoli.com/support/handbook/

Příručka poskytuje informace o tom, jak se obrátit na Zákaznickou podporu Tivoli v závislostina závažnosti vašeho problému, a následující informace:v Registrace a oprávněnost nárokuv Telefonní čísla a adresy elektronické pošty v závislosti na zemi, ve které pracujetev Jaké informace je nutné shromáždit, než se obrátíte na zákaznickou podporu

Konvence používané v této knizeTento průvodce používá několik grafických konvencí pro speciální termíny a akce, příkazy acesty závislé na operačním systému.

Konvence typu písmaV této knize jsou použity tyto konvence typu písma:

Tučné písmo Jména příkazů a voleb, klíčová slova a další informace, které se musí použítpřesně tak, jak jsou uvedeny, jsou vyznačeny tučným písmem.

Kurzíva Proměnné, volby příkazů a hodnoty, které musíte dodat, jsou vyznačenykurzívou. Názvy publikací a speciální slova nebo fráze, které je nutnézdůraznit, jsou také vyznačeny kurzívou.

Monospace Příklady kódů, příkazové řádky, výstup na obrazovce, jména souborů aadresářů a systémové zprávy jsou vyznačeny fontem monospace.

x Access Manager: Průvodce kapacitním plánováním

Plánování kapacit

Plánování kapacit je proces, zabývající se odhadem systémových požadavků a zjištěním, zdavaše prostředí IBM

®

Tivoli®

Access Manager má adekvátní zdroje, aby bylo schopnoobsluhovat požadavky přijatelnou rychlostí.

Tento průvodce byl vytvořen s cílem pokrýt plánování kapacit pro server Access ManagerWebSEAL a související servery. Techniky zde popsané jsou však dostatečně obecné, aby jebylo možné použít také pro jiné distribuované a replikované komunikační systémy.

Všimněte si, že tento průvodce neobsahuje žádná specifická měření. Zajímáte-li se o měřenívýkonnosti, informace najdete ve zprávách o výkonnosti Access Manager, nebo doplňtestávající měření o měření, provedená ve vaší vlastní laboratoři.

Tento průvodce obsahuje následující hlavní části:v Proces plánování kapacitv Vysvětlení možností topologie sítěv Identifikace transakcí serveruv Definice požadavků na průchodnost transakcí serveruv Výběr hardwaruv Získání měření/průchodnostiv Výpočet požadovaného počtu počítačův Vytvoření možností topologie sítěv Příklad plánování kapacit

Proces plánování kapacitProces plánování kapacit začíná u komunikačního systému, který podporuje více topologiísítě, a u představy typu zatížení, jaké musí tento komunikační systém obsloužit. Dalšímkrokem v procesu plánování kapacit je identifikace typů transakcí, které má každý serverzpracovávat, a namapování zatížení na požadavky na průchodnost pro jednotlivé servery. Pakvyberte hardware a shromážděte měření. Tyto požadavky a měření jsou vstupem do výpočtu,který určí podíl počítače nebo počet počítačů, které jsou nezbytné pro každý daný server.Naposled navrhněte topologie sítě.

© Copyright IBM Corp. 2001, 2002 1

Následující vývojový diagram demonstruje proces plánování kapacit:

Přesnost procesu plánování je přímo úměrná přesnosti požadavků na průchodnost a přesnostiodhadů, které jsou vstupy procesu. Tak jako u každého použití plánování, výsledek jeodhadem a předpokládá se určitá tolerance chyb. Tolerance chyb se liší v závislosti na mnohafaktorech, včetně úrovně zkušeností, důvěry v provedená měření, a jak přesně provedenáměření odpovídají budoucím požadovaným transakcím. Všimněte si, že tento průvodce nedělážádná prohlášení týkající se tolerance chyb, která by mohla být předpokládána při použitípopisovaných metod. Určit toleranci chyb je vaším úkolem jako projektanta.

Vysvětlení možností topologie sítěV typickém komunikačním systému existuje několik možností topologie sítě. V tomtokontextu se topologií sítě míní rozdělení serverů mezi několika počítači a jejich síťovápropojení. Chcete-li porozumět topologii sítě, musíte být schopni identifikovat servery vsystému a shromáždit informace o každém serveru. Shromážděte například následujícíinformace:v Určete funkci, kterou provádí každý server v komunikačním systému, a volby, které tento

server podporuje.v Pro každý server určete další servery, se kterými komunikuje.v Určete možnosti kombinace a rozdělení serverů. Obvykle je taková možnost flexibilní.

Každý server může pracovat na samostatném počítači nebo může být kombinován s dalšímiservery.

v Určete, zda je možné servery replikovat nebo ne. Server sice nemusí podporovat vlastníreplikaci, přesto ale může být replikován. V takovém případě je možné provádět replikaciručně.

Servery v prostředí WebSEALV prostředí WebSEAL je zatížení rozloženo na několik serverů. Tabulka 1 obsahuje seznamtěchto serverů spolu s jejich podporou replikace. Pokud plánujete, že nasadíte další servery dostejného prostředí, musíte také vzít do úvahy zatížení pro tyto servery.

Tabulka 1. Servery v prostředí WebSEAL

Server Podpora replikace

WebSEAL (PDWeb) Ano, pomocí prostředku pro vyrovnávání zatížení,jako např. IBM eNetwork Dispatcher

Lightweight Directory Access Protocol (LDAP) Ano, Access Manager může vyvažovat zatíženímezi více LDAP servery

2 Access Manager: Průvodce kapacitním plánováním

Tabulka 1. Servery v prostředí WebSEAL (pokračování)

Server Podpora replikace

Webové servery typu back-end Může vyžadovat ruční replikaci. Access Managermůže vyvažovat zatížení mezi více servery typuback-end.

Možnosti topologie sítě WebSEALNíže jsou uvedeny některé základní topologie sítě WebSEAL:

Jeden počítač: kombinace všech serverův WebSEALv Management serverv LDAP

Dva počítače: WebSEAL a LDAP na samostatných počítačíchv WebSEAL počítač

– WebSEAL– Management server

v LDAP počítač

Tři počítače: WebSEAL, LDAP a webový server typu back-end (spojený) na samostatnýchpočítačíchv WebSEAL počítač

– WebSEAL– Management server

v LDAP počítačv Webový server typu back-end

Plánování kapacit 3

Další topologie je možné vytvořit rozdělením a replikací serverů. Můžete například oddělitManagement server na vlastní počítač a replikovat WebSEAL na více počítačů. V takovémpřípadě byste mohli používat prostředek pro vyrovnávání zatížení, jako např. IBM eNetworkDispatcher, abyste rozdělili zatížení. Můžete také na více počítačů replikovat servery LDAP,případně webové servery typu back-end. WebSEAL podporuje vyrovnávání zatížení apřepnutí při selhání mezi více LDAP servery a webovými servery typu back-end.

Fyzické sítěDalším bodem, který byste měli zvážit a který se týká topologie sítě, jsou možnosti připojeník fyzické síti. Musíte určit, kolik fyzických sítí a s jakými rychlostmi linek je možné využítnebo je potřeba zajistit. Znovu platí, že účel každého serveru může diktovat některé zmožností fyzických sítí.

Šířka pásma sítě může být jedním z důvodů, proč vyžadovat více fyzických sítí. Je-li síťúzkým místem, jedním ze způsobů, jak vyřešit tento problém, je vytvořit více fyzických sítí.Další volbou jsou linky s vyšší rychlostí.

Pro účely plánování kapacit považujte síť za speciální typ serveru. Obsluhuje zatížení. Jsou-limožnosti fyzických sítí známy, považujte každou fyzickou síť za samostatný server. Nebopovažujte celou síť za jeden velký server a rozdělte tuto síť na několik fyzických sítí, je-li tonezbytné. Fyzická síť podporuje replikaci ve významu, že podporuje vytváření podsítí a víceIP adres na jednom počítači.

Identifikace transakcí serveruAž identifikujete všechny servery v komunikačním systému, dalším krokem je určit typyzatížení, o kterém se předpokládá, že bude systém obsluhovat. Vyjádřete zatížení jakotransakce na úrovni systému, a každou transakci na úrovni systému rozdělte na transakce naúrovni systému na jednom nebo více serverů v systému. Tento krok v procesu plánováníkapacit se snaží identifikovat všechny transakce, o kterých se předpokládá, že je bude danýserver provádět. V tomto kroce není nezbytné určit četnost každé transakce. Četnost každétransakce se určí v dalším kroku v procesu — “Definice požadavků na průchodnost transakcíserveru” na stránce 6.

Například, představte si prostředí WebSEAL, ve kterém se transakce na vysoké úrovniskládají z autentizovaného přístupu k webové stránce. Předpokládejme, že přístup ke stráncevyžaduje SSL (Secure Sockets Layer), používá autentizaci pomocí LDAP, dosahuje velikostiv průměru 5 KB a probíhá prostřednictvím TCP spojení WebSEAL. Tento pracovnípožadavek navštíví WebSEAL server, LDAP server, webový server typu back-end a fyzickousíť.

Výsledné transakce serveru jsou následující:

Tabulka 2. Příklad transakcí serveru

Server Transakce

WebSEAL Autentizovaný přístup k webové stránceprostřednictvím SSL k webovému serveru typuback-end s TCP spojením

LDAP Autentizace řízená WebSEAL

Webový server typu back-end Přístup k webové stránce pomocí TCP

Fyzická síť Přibližně 10 KB provoz, včetně malé režie prokomunikaci s LDAP serverem


Transakce v prostředí WebSEALPrimární transakce, transakce na vysoké úrovni v prostředí WebSEAL je přístup k webovéstránce. Několik parametrů definuje přístup k webové stránce. Například jeden parametr je,zda přístup ke stránce zahrnuje i přihlášení uživatele (autentizaci). Další transakcí v prostředíWebSEAL je administrativní aktualizace, jako např. vytvoření, odstranění, výpis nebo změnauživatelů nebo záznamů v ACL. Níže jsou uvedeny některé z parametrů, které týkají definicetransakce v prostředí WebSEAL:v WebSEAL server

– Přístup ke stránce- TCP nebo SSL- Autentizovaný, po-autentizovaný, neautentizovaný- Pokud SSL, nový prohlížeč pro každý požadavek (nová relace SSL) nebo stejný

prohlížeč (opětovné použití relace SSL)- Pokud SSL, velikost paměti cache a časové limity SSL- Pokud autentizovaný, uživatel v paměti cache Access Manager nebo ne- Pokud autentizovaný, špatné přihlášení nebo ne- Odhlášení (požadavek na stránku pkmslogout) nebo ne- Spojen nebo nespojen k webovému serveru typu back-end- Pokud spojen, typ spojení TCP nebo SSL- Pokud spojen, vyžaduje server typu back-end autentizaci nebo ne- Velikost webové stránky

– Administrativa- Vytvořit, odstranit, vypsat nebo změnit uživatele- Vytvořit, odstranit, vypsat nebo změnit ACL

v LDAP server– Autentizace

- Uživatel z paměti cache LDAP, DB2, nebo z disku (neuložený do paměti cache)- Selhání autentizace nebo ne- Pokud selhala autentizace, proč? Uživatel nebyl nalezen nebo neplatné heslo- Velikost registru (počet uživatelů)

– Administrativa- Vytvořit, odstranit, vypsat nebo změnit- Aktualizovat hlavní server LDAP nebo propagovat do repliky LDAP- Pokud aktualizace hlavního serveru LDAP, nastavení replikace (zapnuto nebo

vypnuto)- Četnost propagace (okamžitá nebo pozdržená)- Velikost registru (počet uživatelů)

v Webový server typu back-end– TCP nebo SSL– Autentizovaný, po-autentizovaný, neautentizovaný– Velikost webové stránky

v Fyzická síť– Počet bajtů v každé transakci– Rychlost linky


Definice požadavků na průchodnost transakcí serveruDalším krokem v procesu plánování kapacit je nadefinovat požadavky na průchodnosttransakcí serveru pro každou transakci na každém serveru. To platí, je-li nadefinována četnostkaždé transakce serveru. Pro začátek nadefinujte průchodnosti transakcí na úrovni systému anamapujte je na transakce na úrovni serveru pro každý ze zúčastněných serverů.

Rozhodnout četnost transakcí, nebo také průchodnost, v komunikačním systému jepravděpodobně nejtěžší částí procesu plánování kapacit. Obvykle jde pouze o odhad, a jakotakový může být největší příčinou chyby při výpočtu množství požadovaných počítačů.Chcete-li snížit toleranci chyb, je dobré založit svůj odhad na empirických datech zprodukčních prostředí. To není vždy možné, takže je nutné použít jiné metody, nebokombinaci metod pro odhadnutí průchodnosti transakcí.

Založení odhadů na empirických datechNíže jsou uvedeny způsoby, jak shromáždit empirická data. Proveďte trasování IP paketů avyjměte typy transakcí a jejich četnost během určité doby. Ujistěte se, že protokolováníserveru je zapnuto a zkontrolujte typy a četnost transakcí. Z výstupu podobného trasovánímůžete například určit četnost autentizací a přístupů k webové stránce. Všimněte si, že pokudpoužíváte podobná měření, musíte vzít v úvahu veškeré rozdíly mezi měřeným a plánovanýmprostředím.

Založení odhadů na registrovaných uživatelíchDalším způsobem, jak odhadnout průchodnost transakcí, nebo požadavky, je založit odhadyna počtu uživatelů v registru. Hlavní myšlenkou je, že určité procento uživatelů bude používatsystém během dané doby. Současně je zde názor na to, co průměrný uživatel dělá ve smysluzatěžování systému. Například procento uživatelů v daném čase je autentizační poměr.Autentizační poměr vynásobený zatížením, vygenerovaným průměrným uživatelem, dáváprůchodnost pro průměrnou zátěž.

Všimněte si, že tato metoda má sklon vést k větší toleranci chyb. Níže je uveden příklad tétometody.

Předpokládejme, že v systému je registrováno 2 miliony uživatelů a že přibližně 20% z nich jepřihlášeno (autentizováno) každý den. Dále předpokládejme, že každý uživatel přistupuje k 10webovým stránkám při každé relaci. Požadovaný autentizační poměr je 4,63 autentizací zavteřinu, což bylo vypočítáno z následujícího vzorce:2 000 000 uživatelů * 20 procent/ 24 hodinami za den/ 60minutami za hodinu/ 60 vteřinami za minutu = 4,63autentizací/vteřinu

Požadovaný poměr přístupů ke stránce je 46.3 stránek za vteřinu, což bylo vypočítáno znásledujícího vzorce:4.63 autentizací/vteřinu * 10 stránek na relaci uživatele = 46.3 stránek/vteřinu

To vypadá docela jednoduše. Avšak pokud budete používat tyto vzorce jako nástroj provypracování odhadů, musíte také vzít v úvahu množství ovlivňujících faktorů, jako např.kritérium opětovných autentizací, velikost paměti cache pro uživatele a časové limity. Tatokritéria jsou popsána v následující části a v “Velikost paměti cache pro uživatele a časovélimity WebSEAL” na stránce 7.

Kritéria pro opětovnou autentizaciKdyž počítáte odhady založené na celkovém počtu registrovaných uživatelů, zvažte, jak častose uživatelé musí opětovně autentizovat. Je dobré a rozumné, zkontrolovat tento poměr tak, žespočítáte, jak dlouho by trvalo všem uživatelům provést autentizaci za předpokladu, že není


potřeba žádná opětovná autentizace. V předchozím příkladu by trvalo 5 dnů, aby se každýuživatel autentizoval. Toto číslo bylo obdrženo z následujícího vzorce:2 000 000 uživatelů / 4,63 uživatelů autentizujících se za vteřinu = 431965 vteřin,aby se autentizovali všichni uživatelé (neboli 5 dnů)

Rychlý způsob, jak odvodit tuto odpověď, je zvážit původní prohlášení, že 20% uživatelů sepřihlásí každý den. To znamená, že 100% uživatelů bude trvat 5 dnů, aby se autentizovalo.

Rozumné je zvážit, zda se všech 2 000 000 uživatelů autentizuje během 5 dnů, nebo zda jezde určitý počet probíhajících opětovných autentizací. Například, pokud očekáváte, že 20%uživatelů představuje aktivní část uživatelů, kteří se přihlásí jednou denně, pak poměr 4,63autentizací/vteřinu je přiměřený. Pokud se ale určitý počet z oněch 20% uživatelů musíopětovně autentizovat během dne, pak je poměr 4,63 autentizací/vteřinu příliš malý. Nadruhou stranu může vypadat nerealisticky, že se 400 000 různých uživatelů (což je 20%celkového počtu) bude autentizovat v daný den. Možná, že poměr, který byl odvozen z 20%uživatelů, může zahrnovat i opětovné autentizace.

Velikost paměti cache pro uživatele a časové limity WebSEALJedním z bodů, který je třeba zvážit pro opětovné autentizace, je nastavení velikosti paměticache pro uživatele a časových limitů, které jsou uvedeny v konfiguračním souboru secmgrd.Standardní velikost paměti cache pro uživatele je 4096 a standardní časový limit je jednahodina pro aktivního uživatele a 10 minut pro neaktivního uživatele.

Uživatelé mohou být vytlačeni z paměti cache a donuceni k tomu, aby se opětovněautentizovali, pokud se buď paměť cache zcela zaplnila, nebo pokud byl překročen časovýlimit. Je dobrým nápadem započítat ten nižší z uvedených dvou časů a určit, který z nich jeskutečným omezením doby trvání relace uživatele.

Pokud vezmeme příklad 4,63 autentizací/vteřinu a standardní velikost paměti cacheWebSEAL a standardní časový limit WebSEAL, pak doba, za kterou se naplní paměť cache jecca 15 minut, což bylo vypočítáno z tohoto vzorce:(4096 uživatelů v paměti cache / 4.63 autentizací uživatele/vteřinu) / 60= 14,7 minut

15 minut, za kterých se naplní paměť cache, je kratší doba než jedna hodina, což je časovýlimit pro aktivního uživatele, takže tento parametr omezuje dobu trvání relace uživatele na 15minut, po uplynutí kterých je uživatel nucen se autentizovat (minimálně tehdy, pokud sevyskytuje četnost autentizace v poměru 4,63 autentizací/vteřinu). Pokud se předpokládá, žerelace uživatele bude trvat déle než 15 minut, zvětšete velikost paměti cache pro uživateleWebSEAL, hodnoty časového limitu, nebo obojí, abyste umožnili delší dobu trvání relace.

V tomto příkladu se stalo, že doba trvání relace je omezena 15 minutami, jelikož za tuto dobuse paměť cache zaplní a vytlačí uživatele ven. Nyní předpokládejme, že se odhaduje, že dobatrvání relace uživatele je 20 minut, a použijeme stejný poměr autentizace 4,63autentizací/vteřinu. Velikost paměti cache, která umožní zůstat uživateli v paměti cache podobu 20 minut a pak jej vytlačit ven, je 5 556, což bylo vypočítáno z následujícího vzorce:20 minut * 60 vteřin * 4.63 autentizací/vteřinu = 5556 uživatelů

Všimněte si, že tyto výpočty jsou založeny na jednom serveru WebSEAL. Je-li vytíženíautentizací rozděleno na více serverů WebSEAL, ujistěte se, že používáte vhodný a efektivnípoměr, který se použije pro každý server při výpočtu dob vytlačení uživatele z paměti cacheWebSEAL. Například průměrný poměr autentizací 4,63 autentizací/vteřinu bude 2,32autentizací/vteřinu, pokud se vytížení rozdělí mezi dva servery WebSEAL. Hodnotu 2,32autentizací/vteřinu používejte pro výpočet velikost paměti cache a časů relace uživatele.


Výběr hardwaruHardwarové možnosti mohou nebo nemusí být flexibilní. Můžete mít požadavek na určitý typpočítače nebo sítě, nebo můžete potřebovat provést cenově nejvýhodnější výběr z několikahardwarů. V obou případech si musíte vybrat hardware.

Pokud chcete zhodnotit cenu různých možností hardwaru, pak tento proces můžete provéstpostupně pro každou hardwarovou specifikaci.

Z hlediska počítače jsou volby definovány možnostmi výrobce, čísla modelu, rychlosti CPU apočtu procesorů. Velmi často zvolení určitého hardwaru vynutí zvolit si určitý operačnísystém. To je případ prostředí WebSEAL. Pro účely kapacitního plánování vytížení sepředpokládá, že každý server má dostatečné množství RAM a místa na disku, aby pracovalefektivně.

Z hlediska fyzické sítě jsou vaše volby definovány typem sítě (jako např. ethernet nebo tokenring, optická vlákna), rychlostí linky a výrobcem síťového adaptéru.

Následující část probírá otázky kapacitního plánování vztahující se k hardwaru.

Plánování paměti a místa na diskuS plánováním kapacit souvisí i plánování požadavků na paměť a místo na disku. Pro každýserver v systému si projděte produktovou dokumentaci k serveru a najděte informace, týkajícíse základních požadavků na paměť a místo na disku daného produktu. Z této dokumentacetaké určete veškeré další požadavky pro další položky, jako např. velikost paměti cache aregistrů. Velikost paměti cache ovlivňuje nároky na paměť. Registr uživatelů ovlivňujepožadavky na místo na disku.

Níže jsou uvedeny informace o problematice naladění pamětí cache a registrů v prostředíWebSEAL. WebSEAL, LDAP a DB2 mají paměti cache, které drží informace oautentizovaných uživatelích. WebSEAL má paměť cache, pomocí které udržuje relace SSL, apaměť cache pro webové objekty. Požadavky na paměť jsou přímo úměrné velikosti paměticache a zatížení.

Volbou produktu WebSEAL pro registr je produkt IBM SecureWay Directory. IBMSecureWay Directory drží data registru v tabulkách DB2. Požadavky na místo na disku jsoupřímo úměrné velikosti registru.

Získání měření/průchodnostiV tomto kroku procesu plánování kapacit musíte přizpůsobit všechny identifikovanétransakce serveru skutečným měřením na hardwaru, srovnatelném s tím, který jste si vybrali.Pro účely plánování kapacit potřebujete získat měření maximální průchodnosti pro každý typtransakcí. Maximální průchodnost se obvykle získává zvyšováním zatížení na serveru, dokudse průchodnost nevyrovná a doby odezvy nezačnou být příliš dlouhé.

Měření průchodnosti serveru můžete získat z různých zdrojů, včetně výrobce softwaruserveru, zpráv o výkonnosti od nezávislých společností testujících výkonnost a testování zvaší vlastní laboratoře.

Chcete-li dobře pochopit, co bylo ve skutečnosti změřeno, musíte pečlivě číst veškeré zprávyo měření. Pokuste se najít měření, která nejvíce odpovídají prostředí, do kterého má býtnasazen váš komunikační systém.


Jedním bodem, kterého byste si měli všimnout, je hardware použitý pro měření. Pokuste senajít měření, které co nejvíce odpovídá hardwaru, který chcete nasadit. Pak se pokuste najítzprávy s podobnou architekturou, například se pokuste najít informace o IBM RS/6000,pokud hodláte nasadit RS/6000. Také se pokuste najít podobné rychlosti CPU, operačnísystémy a úrovně operačních systémů.

Pokud taková zpráva o měření není k dispozici, nebo není úplná, je nezbytné odhadnouthodnoty ze stávajících měření, nebo provést nová měření. Následující část vysvětluje některéběžné techniky odhadů, pokud typy transakcí a prostředí neodpovídají dostupným měřením.

Úprava typů transakcí tak, aby odpovídala zprávám o měřeníPokud pro identifikovaný typ transakce serveru neexistuje žádné porovnatelné měření,doporučuje se, abyste rozdělili identifikované transakce serveru na více transakcí na nižšíúrovni, nebo je zkombinovali s dalšími, abyste vytvořili jednu transakci na vyšší úrovni.

Například předpokládejme, že identifikovanou transakcí je autentizovaný přístup k webovéstránce následovaný osmi po-autentizačními přístupy k webové stránce. Tato transakce nenípravděpodobně dostatečně obecná, aby ji bylo možné nalézt ve zprávě o měření. Jepravděpodobné, že bude muset být rozdělena na dvě transakce: autentizovaný přístup kwebové stránce a po-autentizační přístup k webové stránce.

Škálování podle hardwarových rozdílůJedním ze způsobů, jak překlenout rozdíly v hardwaru, je použít publikované srovnávací testy,které jsou k dispozici na následující webové stránce:

http://www.spec.org

SPEC (Standard Performance Evaluation Corporation) nabízí výrobcům hardwaru cestu, jakpublikovat výsledky určitých výkonnostních srovnávacích testů.

Poněvadž mají komunikační programy tendenci vystupovat jako celočíselné aritmeticképrogramy, zajímavé jsou z tohoto hlediska srovnávací testy specint. Pokud chcete najítvýsledky specint, zvolte na webové stránce SPEC CPU95 nebo SPEC CPU2000. Pak zvolteSubmitted Results a buď SPECint95, SPECint_rate95, SPECint2000, neboSPECint_rate2000.

Vyhledejte počítače, o které se zajímáte, v kterémkoliv ze zadaných vyhledávání. Pokudvýsledky srovnávacích testů obsahují oba počítače, použijte výsledky jako měřítko, pomocíkterého budete porovnávat oba počítače. Vzorec je následující:<výkonnost počítače jedna> = <výkonnost počítače dva>* <specint výsledek pro počítač jedna> / <specint výsledek propočítač dva>

Pokud nenajdete výsledky srovnávacího testu, který by obsahoval oba počítače, je možnépoužít prostřední počítač jako prostředníka. Prostřední počítač musí být vypsán ve výsledcíchsrovnávacích testů pro oba počítače, o které se zajímáte. V takovém případě můžete použítsrovnání prvního počítače a prostředního počítače, a pak prostředního počítače a druhéhopočítače.

Pokud se počítač nevyskytuje v žádném z výsledků srovnávacích měření, může mít podobnouarchitekturu jako počítač, který je vypsán ve výsledcích srovnávacích testů. Pro škálování jevhodné použít podobnou architekturu, rychlost CPU nebo výkonnost v MHz. V takovémpřípadě použijte poměr rychlostí CPU pro určení rozdílů mezi oběma počítači.


Rozdíly v operačních systémechAčkoli výsledky srovnávacího testu specint zobrazuje relativní rozdíly ve výkonnosti dvoupočítačů, výsledky těchto srovnávacích testů mají tendenci být méně přesné v oblastipředpovědí výkonnosti komunikačního softwaru, pokud se liší operační systémy. To je proto,že celočíselné aritmetické srovnávací testy neberou v úvahu některé rozdíly specifické prooperační systémy, jako např. škálování pomocí SMP, I/O zpracování, nebo využití zdrojů.Měli byste použít větší toleranci chyb v případě, že mezi porovnávanými počítači je rozdíl voperačních systémech, obzvláště pokud transakce, která vás zajímá, zahrnuje zpracování,které by mohlo být specifické pro daný operační systém.

Škálování podle využití CPU, nižšího než 100%Někdy se stane, že máte k dispozici měření pro transakci, ale tato měření nepředstavujímaximální průchodnost testovaného počítače. Pečlivě čtěte zprávy z měření, abyste určili, zdajsou oznamovány maximální průchodnosti. Níže jsou uvedeny některé body, které byste mělisledovat.

Pokud jsou poskytovány informace o využití CPU, pak pokud bylo naměřeno na serveru nižšívyužití CPU než 100%, pak by to mohlo znamenat, že nebyla změřena maximálníprůchodnost. Je obvyklé a dobré, že servery generující zatížení a neměřené servery běží svyužitím CPU menším než 100%, ale server, který se měří, by měl být využit téměř na 100%.

Pokud data, která získáte, se týkají závislosti průchodnosti na zvyšování zátěže, pak menšínež maximální průchodnost znamená nedostatek vyrovnávání průchodnosti. Pokud vtakových zprávách najdete doby odezvy, dalším příznakem je téměř konstantní nebo pouzemírně se zvyšující doba odezvy při zvyšování zátěže.

Je možné odhadnout maximální průchodnost z měření, ve kterých byla dosažena nižšíprůchodnost než maximální, ale vyžaduje to znalost využití CPU. Tento způsob také vede květší toleranci chyb, neboť softwarové systémy se ne vždy chovají tak, aby dosahovaly nebodokonce přesahovaly maximální průchodnost.

Níže je uveden vzorec, pomocí kterého můžete odhadnou maximální průchodnost z naměřenéprůchodnosti, je-li menší než maximální:Maximální průchodnost = naměřená průchodnost / využití CPU

Například pokud byla měřena průchodnost při 50% využití CPU, pak odhadovaná maximálníprůchodnost je dvojnásobek naměřené hodnoty, jelikož byla využita pouze polovina (50%)počítače.

Škálování podle rozdílů ve velikostech stránekVětšinou každá webová stránka má rozdílnou velikost. Pokud velikosti různých webovýchstránek jsou jediným rozdílem mezi nimi (ve smyslu definice transakce serveru), pak jemožné všechny stránky považovat za jednu průměrně velkou stránku.

Například pokud požadavky na vytížení určují průměrnou relaci uživatele, která se skládá zetří přístupů k 5KB stránkám, dvou přístupů k 10KB stránkám a jednoho přístupu k 15 KBstránce, pak ekvivalentní velikost stránky pro účely plánování kapacit je 8,3 KB. V tomtopříkladu byla průměrná velikost stránky vypočítána takto:((3 * 5 KB stránky) + (2 * 10 KB stránky) + (1 * 15 KB stránka)) /6 celkový počet stránek = 8.3 KB průměrná stránka

Ve většině případů není možné najít měření týkající se přístupu k webovým stránkám propřesně definovanou velikost stránky dle požadavků na vytížení. Zprávy z měření mohou místotoho obsahovat seznam průchodností pro dvě nebo více různých velikostí stránek. Je-li dána


průchodnost pro dva přístupy k webové stránce, a jsou-li ostatní parametry transakce serverustejné, můžete odhadnout průchodnost jakékoliv obecné velikosti stránky.

Odhad je založen na přímce procházející dvěma body. Jelikož grafy průchodnosti vypadajíjako funkce y=1/x, musíte použít nepřímou hodnotu průchodnosti pro lineární extrapolaci.

Nejprve se představíme trochu matematiky. Aby bod byl na stejné přímce jako další dva body,sklon všech bodů na přímce musí být stejný. Předpokládejme například, že máme dva body:(x1,y1) a (x2,y2). Aby byl třetí bod (x,y) na stejné přímce, musí platit tento vzorec:(y - y1) / (x - x1) = (y1 - y2) / (x1 - x2)

Řešení pro y je následující:y = (x - x1) * (y1 - y2) / (x1 - x2) + y1

Pokud vztáhneme rovnici zpět k velikostem stránek, pak x představuje velikost stránky a ypředstavuje nepřímou hodnotu průchodnosti, která vystupuje jako přímka. V následujícírovnici byla všechna y převrácena, takže y nyní představuje průchodnost:1/y = (x - x1) * (1/y1 - 1/y2) / (x1 - x2) + 1/y1

Opětovným vyřešením této rovnice pro y získáme následující vzorec:y = 1 / ((x - x1) * (1/y1 - 1/y2) / (x1 - x2) + 1/y1)

V tomto vzorci mají jednotlivé proměnné následující definice:v x je odhadovaná velikost stránkyv y je odhadovaná průchodnost pro velikost stránky xv x1 je první velikost stránky, pro kterou byla měřena průchodnostv x2 je druhá velikost stránky, pro kterou byla měřena průchodnostv y1 je naměřená průchodnost první velikosti stránkyv y2 je naměřená průchodnost pro druhou velikost stránky

Škálování podle velikosti stránky a zabudovaných obrázkůBuďte opatrní při odhadování průchodnosti webových stránek, které mají zabudovány několikobjektů, jako např. soubory .gif a .jpg. Musíte pokládat každý objekt, hlavní stránku avšechny zabudované obrázky jako samostatné přístupy k webové stránce. Doporučuje sezprůměrovat velikost webových stránek (jak bylo vysvětleno v dřívějším příkladu).Nepovažujte celou sadu objektů za jeden přístup k velké webové stránce. Jinými slovy,zprůměrujte velikosti, nesčítejte je dohromady. Transakcí je několik, nikoliv jedna. Důvod,proč je toto tak důležité, je, že průchodnost jedné velké stránky je mnohem lepší než několikamalých stránek.

Škálování podle rozdílů ve fyzických sítíchPokud se fyzická síť použitá ve zprávě z měření odlišuje od fyzické sítě, kterou chcete nasadit,rozdíl není obvykle předmětem starostí ve smyslu průchodnosti, které jsou dané serveryschopny dosáhnout. To je způsobeno tím, že rozdíly v rychlostech linek neovlivňují schopnostserveru pracovat. Tento rozdíl může ale způsobit problémy, pokud karta síťového adaptérusilně využívá CPU. To však není typickým případem. Jako ochrana před takovým případemse doporučuje používat velmi kvalitní a vysoce hodnocené karty síťových adaptérů.

Rozdíly ve fyzických sítích ovlivňují kapacitu nebo průchodnost sítě. Pro plánování kapacitfyzické sítě byste měli získat zprávy z měření průchodnosti fyzické sítě. Případně je možnéprůchodnost fyzické sítě odhadnout jako určité procento její teoretické přenosové rychlosti.Například 100Mbps Ethernet může snadno dosáhnout přenosové rychlosti 7 MB za vteřinu připoužívání FTP protokolu, což je 70% teoretické přenosové rychlosti. Kapacita fyzické sítě je


obvykle méně důležitá, neboť většina fyzických sítí dosahuje vyšších přenosových rychlostí.Přesto se doporučuje, abyste dali nějaká kritéria na kapacitu fyzické sítě.

Výpočet požadovaného počtu počítačůAž nadefinujete transakce a požadavky na každý server a přiřadíte je k měřením, je časvypočítat počet počítačů, které budou potřeba, aby splnily požadavky.

Počet počítačů je založen na požadavcích, rozdělených na dosažitelné, nebo měřitelné.Například pokud požadavek je dvojnásobek dosažitelného, pak je výsledek dva. To znamená,že jsou třeba dva počítače k tomu, aby byly splněny požadavky.

Poměry jsou vypočítány pro každý typ transakce daného serveru, a pak jsou všechny dánydohromady, aby byl získán celkový obrázek daného serveru. Výpočet se opakuje pro každýserver. Tento výpočet zahrnuje fyzickou síť, která se považuje z hlediska plánování kapacit zaspeciální typ serveru.

Pokud počet potřebných počítačů je menší než jedna, pak tento poměr představuje částpočítače, kterou je třeba vyhradit pro zpracování.

Vzorec pro výpočet je následující:Faktor počítače = R1/M1 + R2/M2 + R3/M3 + . . . + Rn/Mn

Definice proměnných v tomto formuláři jsou:v Faktor počítače určuje část jednoho nebo počet počítačů, který je potřeba pro daný server.v n určuje počet transakcí, identifikovaných pro daný server.v R1... Rn určuje požadavky na průchodnost pro transakce 1 až n.v M1 ... Mn určuje měření průchodnosti pro transakce 1 až n.

Zvyšování počtu počítačůJe dobré zvýšit počet potřebných počítačů o nějaké procento. Důvody, proč to tak udělat,zahrnují započítání chyb při odhadech, budoucí nárůst a využití ve špičce. Doporučuje se,abyste zvýšili počet počítačů minimálně o 20%, abyste započítali tyto faktory.

Vytvoření možností topologie sítěPokud počet počítačů potřebných pro daný server je více než jedna, a pokud počítač nelzereplikovat, pak je potřeba rychlejší počítač. Zvolte rychlejší počítač a zopakujte krokyplánování kapacit pro tento server.

Pokud je poměr pro fyzickou síť větší než jedna, pak průchodnost přesahuje možnosti šířkypásma nebo rychlosti linky. Zvolte rychlejší síť nebo rozdělte komunikační systém na vícepodsítí.

Pokud počet počítačů potřebných pro server je menší než jedna, je možné, že by tento servermohl být zkombinován s jiným serverem, který také vyžaduje méně než jeden počítač.

Všimněte si, že rozhodnutí o topologii sítě je založeno na vyrovnávání vytížení. Dalšímifaktory, které ovlivňují výběr topologie sítě, zahrnují přepnutí při selhání, zálohování, využitízdrojů a ochranu pomocí firewallu. Tyto faktory nejsou zahrnuty v tomto dokumentu.


Příklad plánování kapacitNásledující příklad vás provede krok po kroku procesem plánování kapacit pro fiktivníspolečnost.

Vysvětlení možností topologie sítěPředpokládejme, že možnosti topologie sítě jsou limitovány na následující případ:

WebSEAL se používá k ochraně zdrojů na webovém serveru typu back-end

WebSEAL je umístěn na DMZ, který připojuje uživatele internetu na jedné fyzické síti naintranetové webové servery typu back-end na jiné fyzické síti. LDAP se používá jako registr aje umístěn na intranetu z důvodu zabezpečení. Všechny servery podporují replikaci.

Identifikace transakcí serveruPředpokládejme, že běžné parametry, které definují transakci přístupu k webové stránce, jsounásledující:v Access Manager se připojuje k webovému serveru typu back-end prostřednictvím TCP

spojení s volbami, které filtrují původní totožnost uživatele a nahrazují ji totožnostíposkytovanou produktem WebSEAL (volby –B, –U a –W). Ve WebSEAL jsounadefinovány přístupové seznamy, aby chránily zdroje webového serveru typu back-end.

v Autentizace je naladěna tak, jak je popsáno v knize IBM Tivoli Access ManagerPerformance Tuning Guide.

v Průměrná velikost webové stránky je 10 KB.

Předpokládejme, že byly indentifikovány následující transakce na vysoké úrovni:v Stránka TCP—Uživatel podá požadavek na HTTP (TCP) webovou stránku, který jde přes

WebSEAL na webový server typu back-end. Není třeba žádná autentizace.v Stránka se SSL autentizací—Uživatel podá výchozí požadavek na HTTPS (SSL)

webovou stránku, která jde přes WebSEAL na webový server typu back-end. Nastaneautentizace.

v Stránka se zpracováním následujícím po autentizaci SSL—Uživatel vydá dalšípožadavek pro HTTPS (SSL) webovou stránku, který jde přes WebSEAL na webovýserver typu back-end. Není třeba žádná autentizace.

Transakce na vysoké úrovni se rozdělí na následující transakce serveru:

Tabulka 3. Příklad transakcí serveru

Server Transakce

WebSEAL 10 KB TCP přístup ke stránce prostřednictvímTCP spojení, 10 KB SSL přístup ke stránce sautentizaci prostřednictvím TCP spojení, 10 KBSSL přístup ke stránce již autentizovanéprostřednictvím TCP spojení

LDAP Autentizace

Webový server typu back-end 10 KB TCP přístup ke stránce, již autentizované(Access Manager se autentizuje k webovémuserveru typu back-end řídce, což je definovánoserverem typu back-end, dostatečně řídce na to,aby tento počet byl nevýznamný)

Internetová síť 10 KB požadavky na webovou stránku plushlavičky SSL, TCP, HTTP a IP


Tabulka 3. Příklad transakcí serveru (pokračování)

Server Transakce

Intranetová síť 10 KB požadavky na webovou stránku a 200 bajtůvyhledávání LDAP plus hlavičky TCP, HTTP a IP

Definice požadavků na průchodnost transakcí serveruPředpokládejme, že trasování IP ukazuje, že typická relace uživatele se skládá z následujícíchpožadavků:v 3 TCP stránkyv 1 SSL stránka vyžadující autentizaciv 9 SSL stránek po autentizaci

Dále předpokládejme, že trasování ukázalo, že autentizace uživatele se vyskytuje jednou za 5vteřin.

Požadavky na průchodnost celým systémem jsou tedy následující:v Přístupy ke stránkám SSL vyžadujících autentizaci: 5 za vteřinuv Přístupy ke stránkám SSL po autentizaci: 9*5 = 45 za vteřinuv Přístupy ke stránkám TCP: 3*5 = 15 za vteřinu

Níže jsou uvedeny požadavky na průchodnost serveru:

Tabulka 4. Příklad požadavků na průchodnost

Server Transakce Požadavky na průchodnost

WebSEAL 10 KB TCP přístup ke stránceprostřednictvím TCP spojení

15 transakcí/vteřinu

10 KB SSL přístup ke stránce sautentizací prostřednictvím TCPspojení


10 KB SSL přístup ke stránce,již autentizované,prostřednictvím TCP spojení


LDAP Autentizace 5 transakcí/vteřinu

Webový server typu back-end 10 KB TCP přístup ke stránce 65 transakcí/vteřinu

Internetová síť 10 KB požadavky na webovoustránku plus hlavičky SSL, TCP,HTTP a IP

780 KB/vteřinu

Intranetová síť 10 KB požadavky na webovoustránku a 200 bajtů vyhledáváníLDAP plus hlavičky TCP, HTTPa IP

781 KB/vteřinu

Požadavek na průchodnost internetovou sítí byl vypočítán následujícím způsobem:(15 TCP stránek/vteřinu + 50 SSL stránek/vteřinu) * 10 KB/stránku => 650KB/vteřinu + 20% hlavičky = 780 KB/vteřinu

Požadavek na průchodnost intranetovou sítí byl vypočítán následujícím způsobem:650 KB/vteřinu požadavek na internet + (5 SSL autentizací/vteřinu) * 200bajtů => 651 + 20% hlavičky = 781 KB/vteřinu


Výběr hardwaruPředpokládejme, že jste si pro všechny servery vybrali Sun Enterprise 450. Model E450 jepočítač se 4 procesory 400 Mhz UltraSPARC-II.

Dále předpokládejme, že pro obě sítě jste si zvolili 100 Mbps Ethernet.

Získání měření/průchodnostiPředpokládejme, že jste získali následující fiktivní měření pro Sun E450, která jsou uvedena včásti Tabulka 5:

Tabulka 5. Příklad měření

Server Transakce Měření maximálníprůchodnosti

WebSEAL 100 bajtů TCP přístup ke stránceprostřednictvím TCP spojení


5 KB TCP přístup ke stránceprostřednictvím TCP spojení


10 KB SSL přístup ke stránceprostřednictvím TCP spojení

655 transakcí/vteřinu(odhadnuto, viz vzorec popsanýna touto tabulkou)

10 KB SSL přístup ke stránce sautentizací prostřednictvím TCPspojení


10 KB SSL přístup ke stránce,již autentizované,prostřednictvím TCP spojení


LDAP Autentizace 35 transakcí/vteřinu

Webový server typu back-end 10 KB TCP přístup ke stránce 750 transakcí/vteřinu

Internetová síť 10 KB požadavky na webovoustránku plus hlavičky SSL, TCP,HTTP a IP.

7+ MB/vteřinu

Intranetová síť 10 KB požadavky na webovoustránku a 200 bajtů vyhledáváníLDAP plus hlavičky TCP, HTTPa IP

7+ MB/vteřinu

Když porovnáte tabulky Tabulka 5 a Tabulka 4 na stránce 14, vidíte, že odpovídající měřeníexistují pro všechny případy, kromě WebSEAL TCP přístupu ke stránce. Obvykle existujevíce rozdílů mezi požadavky a měřením, než je tomu u tohoto příkladu, ale z důvoduzjednodušení příkladu bylo rozhodnuto zobrazit pouze jeden rozdíl.

Proveďte škálování podle rozdílu ve velikosti TCP stránek tak, jak bylo popsáno v části“Škálování podle rozdílů ve velikostech stránek” na stránce 10. Odhadovaná propustnost proWebSEAL 10 kilobajtů (KB) TCP přístup ke stránce, odhadnutá z měření propustnosti 100bajtového a 4 KB případu, je 655 stránek/vteřinu a byla vypočítána podle následujícíhovzorce:y = 1 / ((x - x1) * (1/y1 - 1/y2) / (x1 - x2) + 1/y1)y = 1 / ((x - 100) * (1/750 - 1/700) / (100 - 5*1024)+ 1/750)1 / ((10*1024 - 100) * (1/750 - 1/700) / (100 - 5*1024)+ 1/750)= 655


Výpočet požadovaného počtu počítačůTabulka 6 na stránce 16 obsahuje seznam požadavků a měření spolu s identifikovanýmitransakcemi serveru.

Tabulka 6. Příklad transakcí, požadavků a měření

Server Transakce Požadavky naprůchodnost

Měření maximálníprůchodnosti

WebSEAL 10 KB TCP přístup kestránce prostřednictvímTCP spojení

15 /vteřinu 655 transakcí/vteřinu(odhadnuto)

10 KB SSL přístup kestránce s autentizacíprostřednictvím TCPspojení

5 /vteřinu 40 transakcí/vteřinu

10 KB SSL přístup kestránce, jižautentizované,prostřednictvím TCPspojení


LDAP Autentizace 5 /vteřinu 35 transakcí/vteřinu

Webový server typuback-end

10 KB TCP přístup kestránce


Internetová síť 10 KB požadavky nawebovou stránku plushlavičky SSL, TCP,HTTP a IP

780 KB/vteřinu 7+ MB/vteřinu

Intranetová síť 10 KB požadavky nawebovou stránku a 200bajtů vyhledáváníLDAP plus hlavičkyTCP, HTTP a IP

781 KB/vteřinu 7+ MB/vteřinu

Informace uvedené v tabulce Tabulka 6 se používají pro výpočet faktorů počítače v tabulceTabulka 7:

Tabulka 7. Příklad výpočtu faktoru počítače

Server Výpočet Faktor počítače Navýšení o 20%

WebSEAL 15/655 + 5/40 +45/2500

.33 0.39

LDAP 5/350 .140 .17

Webový server typuback-end

65/7500 .090 .10

Internetová síť 780/70000 .110 .13

Intranetová síť 780/70000 .110 .13

Poněvadž všechny faktory počítače jsou menší než jedna, každý server využije pouze částpočítače, danou faktorem. Jinými slovy, faktor vynásobený 100 dává procento využitípočítače. V případě sítě také udává odhadované vytížení sítě.


Vytvoření možností topologie sítěJelikož žádný počítač není plně využit, nemusíte uvažovat o kombinaci počítačů. Pokud todovolí bezpečnostní politiky, mohly by všechny servery být umístěny na jednom počítači,který by stále ještě nebyl plně využit.


Poznámky

Tyto informace jsou určeny pro produkty a služby nabízené v USA. Společnost IBM nemusí vostatních zemích nabídnout produkty, služby a funkce popsané v tomto dokumentu. Informaceo produktech a službách, které jsou momentálně ve vaší zemi dostupné, můžete získat odzástupce společnosti IBM pro vaši oblast. Žádný z odkazů na produkty, programové vybavenínebo služby není zamýšlen jako tvrzení, že lze použít pouze tyto produkty, programovévybavení nebo služby společnosti IBM. Jako náhrada mohou být použity libovolné funkčněekvivalentní produkty, programové vybavení nebo služby, které neporušují žádné intelektuálnívlastnické právo společnosti IBM. Za operace prováděné produkty, programovým vybavenímnebo službami, které nepochází od společnosti IBM, nese zodpovědnost uživatel.

Společnost IBM může mít k dispozici patenty nebo podané patentové přihlášky, vztahující sek informacím popsaným v tomto dokumentu. Vlastnictví tohoto dokumentu vám nedávážádná práva k těmto patentům. Písemné žádosti o licenci můžete posílat na adresu:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

Pokud máte zájem o licenci v zemi s dvojbajtovou znakovou sadou (DBCS), kontaktujtezastoupení společnosti IBM ve vaší zemi, nebo písemně zastoupení společnosti IBM naadrese:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan

Následující odstavec se netýká Velké Británie nebo kterékoliv jiné země, kde takováopatření odporují místním zákonům: SPOLEČNOST INTERNATIONAL BUSINESSMACHINES CORPORATION TUTO PUBLIKACI POSKYTUJE TAKOVOU, “JAKÁ JE”,BEZ JAKÝCHKOLIV ZÁRUK, VYJÁDŘENÝCH NEBO ODVOZENÝCH, VČETNĚ,ALE NE VÝHRADNĚ, ODVOZENÝCH ZÁRUK PORUŠENÍ ZÁKONŮ, PRODEJNOSTINEBO VHODNOSTI PRO URČITÝ ÚČEL. Některé právní řády nepřipouštějí omezení čivyvázání se ze záruk nebo odpovědnosti za následné či nepředvídatelné škody. V takovémpřípadě se na vás výše uvedené omezení nevztahuje.

Tato publikace může obsahovat technické nepřesnosti nebo typografické chyby. Informacezde uvedené jsou pravidelně aktualizovány a v příštích vydáních této publikace již budoutyto změny zahrnuty. Společnost IBM má právo kdykoliv bez upozornění zdokonalovat neboměnit produkty a programy popsané v této publikaci.

Všechny odkazy na tyto informace, uvedené na webových stránkách jiných provozovatelů nežspolečnosti IBM jsou poskytovány pouze pro vaši potřebu a v žádném případě neslouží kpropagaci těchto webových stránek. Materiály, uvedené na takovýchto webových stránkáchnejsou součástí materiálů, určených pro tento produkt IBM, a proto tyto webové stránkypoužíváte pouze na vlastní riziko.

Společnost IBM může používat nebo distribuovat informace, které jí poskytnete, způsobem, okterém si myslí, že je odpovídající, bez dalších závazků k vám.


Držitelé licence tohoto programu, kteří si přejí mít přístup i k takovým informacím za účelem(i) výměny informací mezi nezávisle vytvořenými programy a jinými programy (včetnětohoto) a (ii) vzájemného použití sdílených informací, mohou kontaktovat:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78759U.S.A.

Informace tohoto typu mohou být za odpovídajících podmínek dostupné. V některýchpřípadech připadá v úvahu zaplacení poplatku.

Program popsaný v tomto dokumentu a všechny materiály s ním související, které podléhajílicenci, jsou dodávány společností IBM v souladu s textem smlouvy mezi zákazníkem aspolečností IBM nebo ekvivalentní smlouvy.

Všechny informace o provozu byly určeny v řízeném prostředí. Výsledky obdržené v jinémoperačním prostředí se tudíž mohou výrazně lišit. Některá měření byla provedena v systémechs vývojovým prostředím a neexistuje žádná záruka, že tato měření budou stejná v obecnědostupných systémech. Některá měření byla odhadnuta extrapolací. Skutečné výsledky semohou lišit. Uživatelé tohoto dokumentu by měli ověřit vhodnost dat pro svá specifickáprostředí.

Informace týkající se produktů jiných společností byly získány od dodavatelů těchtoproduktů, z jejich tištěných materiálů nebo z jiných veřejně dostupných zdrojů. SpolečnostIBM netestovala tyto produkty a nemůže potvrdit spolehlivost jejich provozu, kompatibilitunebo jiné tvrzení týkající se těchto produktů. Otázky týkající se možností produktů jinýchspolečností by měly být adresovány dodavatelům těchto produktů.

Všechna tvrzení o budoucím zaměření nebo úmyslech společnosti IBM mohou být bezupozornění změněna nebo zrušena a představují pouze hrubý nástin cílů a podmínekspolečnosti.

Tyto informace obsahují příklady dat a sestav, používaných v běžných denních obchodníchoperacích. Aby tyto příklady byly maximálně úplné a demonstrativní, obsahují jména osob,společností, obchodních značek a produktů. Všechna tato jména jsou fiktivní a jakákolivpodobnost se jmény a adresami, používanými skutečnými obchodními společnostmi je čistěnáhodná.

AUTORSKÉ PRÁVO:

Tyto informace obsahují vzorové aplikační programy, uvedené ve zdrojovém jazyce, kterédemonstrují techniku programování na různých operačních systémech. Tyto vzorovéprogramy můžete kopírovat, modifikovat a distribuovat v jakékoliv formě za účelem vývoje,používání, prodeje nebo distribuce aplikačních programů, podřizujících se aplikačnímuprogramovému rozhraní pro daný operační systém, pro který byly tyto vzorové programynapsány, aniž byste museli platit IBM poplatky. Tyto příklady nebyly pečlivě testovány zavšech podmínek. Z tohoto důvodu společnost IBM nemůže zaručit nebo odvodit jejichspolehlivost, obslužnost nebo funkcionalitu. Tyto vzorové programy můžete kopírovat,modifikovat a distribuovat v jakékoliv formě za účelem vývoje, používání, prodeje nebodistribuce aplikačních programů, podřizujících se aplikačnímu programovému rozhraníspolečnosti IBM, aniž byste museli společnosti IBM platit poplatky.

Pokud si tyto informace neprohlížíte v kopii s trvalým záznamem, je možné, že se nezobrazilyfotografie a barevné ilustrace.


Ochranné známkyNásledující termíny jsou ochranné známky společnosti International Business MachinesCorporation v USA, v jiných zemích nebo obojí:

AIXIBMIBM logoSecureWayTivoliTivoli logo

Microsoft, Windows a logo Windows jsou ochranné známky nebo registrované ochrannéznámky společnosti Microsoft Corporation.

UNIX je registrovaná ochranná známka v USA a v dalších zemích, jejíž licenci poskytujevýhradně společnost X/Open Company Limited.

Další jména společností, produktů nebo služeb mohou být ochrannými známkami jinýchspolečností.

Poznámky 21

Rejstřík

CCPU, škálování podle využití menšího než 100% 10

Ččasové limity, WebSEAL 7

Ddefinice průchodnosti transakce serveru 5definice průchodnosti transakcí serveru 6

Ee-mail kontakt ixempirická data, odhady založené na 6

Ffaktor počítače 12, 16faktor, počítač 12, 16fyzické sítě 4, 11

Hhardware

škálování podle rozdílů 9výběr 8

CHchyby, tolerance 2

IIBM SecureWay Directory 8identifikace transakcí serveru 4

Kknihy

objednání vonline vzpětná vazba v

kritériakapacita fyzické sítě 12opětovná autentizace 6

kritéria pro opětovnou autentizaci 6

LLDAP

IBM SecureWay Directory 8server 2, 4, 5

Mmanuály


měření, získání 8místo na disku a paměť 8možnosti

hardware 8topologie sítě 2, 12topologie sítě (WebSEAL) 3

Oobjednání publikací ixodhady

založené na empirických datech 6založené na registrovaných uživatelích 6

online publikace ix

Ppaměť a místo na disku 8plánování kapacit

definice požadavků na průchodnost transakcí serveru 6identifikace transakcí serveru 4procedura 2proces 1přehled 1příklad 13výběr hardwaru 8výpočet požadovaného počtu počítačů 12vysvětlení možností topologie sítě 2vytvoření možností topologie sítě 12získání měření/průchodnosti 8

počet počítačů, výpočet 12počítače

výpočet požadovaného počtu 12zvyšování počtu 12

požadavky, definice průchodnosti transakcí serveru 6procedura, plánování kapacit 2proces, plánování kapacit 1prostředí WebSEAL 5

časové limity 7možnosti topologie sítě 3servery v 2transakce v 5velikost paměti cache pro uživatele 7

průchodnostdefinice transakcí serveru 6

průchodnostipoměry 8

přehled, plánování kapacit 1příklad, plánování kapacit 13přístup k webové stránce 5publikace



Rregistrovaní uživatelů, odhady 6rozdíly

operační systémy 10škálování podle fyzických sítí 11škálování podle hardwaru 9škálování podle velikostí stránek 10

rozdíly v operačních systémech 10rychlost linky 4

Sservery

identifikace transakcí 4protokolování 6shromáždění informací 2v prostředí WebSEAL 2

shromážděníempirická data 6informace o serveru 2

sítě, fyzické 4srovnávací testy 9Standard Performance Evaluation Corporation (SPEC) 9

Ššířka pásma sítě 4šířka pásma, síť 4škálování

hardwarové rozdíly 9škálování podle

rozdíly ve fyzických sítích 11rozdíly ve velikostech stránek 10velikost stránky 11využití CPU menší než 100% 10zabudované obrázky 11

Ttolerance chyb 2topologie sítě, možnosti 2, 12topologie, síť 2, 3transakce

definice průchodnosti serveru 6identifikace serveru 4v prostředí WebSEAL 5

trasování IP paketů 6

Uúprava typů transakcí tak, aby odpovídala zprávám o měření 9

Vvelikost paměti cache pro uživatele, WebSEAL 7velikost stránky

škálování podle 11škálování podle rozdílů 10výpočet průměru 10

výběr hardwaru 8vysvětlení možností topologie sítě 2vytvoření možností topologie sítě 12vzorce

odhad maximální průchodnosti 10

vzorce (pokračování)opětovná autentizace registrovaných uživatelů 7požadovaný počet počítačů 12velikost paměti cache pro uživatele WebSEAL 7výpočet průměrné velikosti stránky 10

vzorec pro průměrnou velikost stránky 10

Zzabudované obrázky, škálování podle 11Zákaznická podpora xZákaznická podpora Tivoli xzpětná vazba o publikacích ixzprávy o měření, shoda 9zvyšování počtu počítačů 12


Vytištěno v Dánsku společností IBM Danmark A/S.

GC09-3668-00

IBM Tivoli Access Manager fileÚvod IBM ®Tivoli Access Manager (Access Manager) je základní...

Documents

Transcript of IBM Tivoli Access Manager fileÚvod IBM ®Tivoli Access Manager (Access Manager) je základní...