Návrh globálně dostupných služeb pomocí Azure SQL DatabaseDesigning globally available services using Azure SQL Database

Při sestavování a nasazování cloudových služeb pomocí Azure SQL Database použijete aktivní skupiny geografických replikace nebo automatického převzetí služeb při selhání k zajištění odolnosti proti místním výpadkům a závažným chybám.When building and deploying cloud services with Azure SQL Database, you use active geo-replication or auto-failover groups to provide resilience to regional outages and catastrophic failures. Stejná funkce vám umožní vytvářet globálně distribuované aplikace optimalizované pro místní přístup k datům.The same feature allows you to create globally distributed applications optimized for local access to the data. Tento článek popisuje běžné aplikační vzory, včetně výhod a kompromisů jednotlivých možností.This article discusses common application patterns, including the benefits and trade-offs of each option.

Poznámka

Pokud používáte databáze úrovně Premium nebo Pro důležité obchodní informace a elastické fondy, můžete je v případě, že je převedete do konfigurace redundantního nasazení zóny, zajistit odolnost proti regionálním výpadkům.If you are using Premium or Business Critical databases and elastic pools, you can make them resilient to regional outages by converting them to zone redundant deployment configuration. Viz zóna – redundantní databáze.See Zone-redundant databases.

Scénář 1: použití dvou oblastí Azure pro kontinuitu podnikových aplikací s minimálními výpadkyScenario 1: Using two Azure regions for business continuity with minimal downtime

V tomto scénáři mají aplikace následující vlastnosti:In this scenario, the applications have the following characteristics:

  • Aplikace je aktivní v jedné oblasti Azure.Application is active in one Azure region
  • Všechny relace databáze vyžadují pro data přístup pro čtení a zápis (RW).All database sessions require read and write access (RW) to data
  • Aby se snížila latence a náklady na provoz, musí být společně umístěnéhoa webová vrstva a Datová vrstva.Web tier and data tier must be collocated to reduce latency and traffic cost
  • V podstatě je výpadkům pro tyto aplikace vyšší riziko, než je ztráta dat.Fundamentally, downtime is a higher business risk for these applications than data loss

V tomto případě je topologie nasazení aplikace optimalizována pro zpracování regionálních havárií, pokud všechny součásti aplikace potřebují převzetí služeb při selhání společně.In this case, the application deployment topology is optimized for handling regional disasters when all application components need to failover together. Následující diagram znázorňuje tuto topologii.The diagram below shows this topology. V případě geografické redundance jsou prostředky aplikace nasazeny do oblastí A a B. Prostředky v oblasti B se ale nevyužívají, dokud nebude oblast A neúspěšná.For geographic redundancy, the application’s resources are deployed to Region A and B. However, the resources in Region B are not utilized until Region A fails. Skupina převzetí služeb při selhání je nakonfigurovaná mezi dvěma oblastmi pro správu připojení k databázi, replikaci a převzetí služeb při selhání.A failover group is configured between the two regions to manage database connectivity, replication and failover. Webová služba v obou oblastech je nakonfigurována pro přístup k databázi prostřednictvím naslouchacího procesu pro čtení a zápis <převzetí služeb při selhání-název skupiny>. Database.Windows.NET (1).The web service in both regions is configured to access the database via the read-write listener <failover-group-name>.database.windows.net (1). Traffic Manager je nastavený tak, aby používal metodu směrování priority (2).Traffic manager is set up to use priority routing method (2).  

Poznámka

Azure Traffic Manager se v tomto článku používá jenom pro ilustraci.Azure traffic manager is used throughout this article for illustration purposes only. Můžete použít jakékoli řešení vyrovnávání zatížení, které podporuje metodu směrování priority.You can use any load-balancing solution that supports priority routing method.

Následující diagram znázorňuje tuto konfiguraci před výpadkem:The following diagram shows this configuration before an outage:

Scénář 1.

Po výpadku primární oblasti zjistí služba SQL Database, že primární databáze není dostupná, a aktivuje převzetí služeb při selhání sekundární oblastí na základě parametrů zásady automatického převzetí služeb při selhání (1).After an outage in the primary region, the SQL Database service detects that the primary database is not accessible and triggers failover to the secondary region based on the parameters of the automatic failover policy (1). V závislosti na vaší smlouvě SLA vaší aplikace můžete nakonfigurovat dobu odkladu, která určuje dobu mezi detekcí výpadku a samotným převzetím služeb při selhání.Depending on your application SLA, you can configure a grace period that controls the time between the detection of the outage and the failover itself. Je možné, že Traffic Manager iniciuje převzetí služeb při selhání koncového bodu předtím, než skupina převzetí služeb při selhání spustí převzetí služeb při selhání databázeIt is possible that traffic manager initiates the endpoint failover before the failover group triggers the failover of the database. V takovém případě se webová aplikace nemůže okamžitě znovu připojit k databázi.In that case the web application cannot immediately reconnect to the database. Ale opětovné připojení proběhne automaticky, jakmile se převzetí služeb při selhání databáze dokončí.But the reconnections will automatically succeed as soon as the database failover completes. Když se neúspěšná oblast obnoví a vrátí zpět do stavu online, stará primární primární se automaticky znovu připojí jako nová sekundární.When the failed region is restored and back online, the old primary automatically reconnects as a new secondary. Následující obrázek znázorňuje konfiguraci po převzetí služeb při selhání.The diagram below illustrates the configuration after failover.

Poznámka

Všechny transakce potvrzené po převzetí služeb při selhání se při opětovném připojení ztratí.All transactions committed after the failover are lost during the reconnection. Po dokončení převzetí služeb při selhání se aplikace v oblasti B bude moci znovu připojit a znovu spustit zpracování uživatelských požadavků.After the failover is completed, the application in region B is able to reconnect and restart processing the user requests. Webová aplikace i primární databáze jsou nyní v oblasti B a zůstávají společně umístěné.Both the web application and the primary database are now in region B and remain co-located.

Scénář 1.

Pokud dojde k výpadku v oblasti B, proces replikace mezi primární a sekundární databází se pozastaví, ale propojení mezi dvěma zůstává beze změny (1).If an outage happens in region B, the replication process between the primary and the secondary database gets suspended but the link between the two remains intact (1). Správa provozu detekuje, že připojení k oblasti B je přerušeno a označuje, že je webová aplikace koncového bodu 2 poškozená (2).Traffic managed detects that connectivity to Region B is broken and marks the endpoint web app 2 as Degraded (2). V takovém případě není ovlivněn výkon aplikace, ale databáze je vystavena a je proto vyšší riziko ztráty dat v případě, že dojde k chybě v oblasti A v případě úspěchu.The application's performance is not impacted in this case, but the database becomes exposed and therefore at higher risk of data loss in case region A fails in succession.

Poznámka

Pro zotavení po havárii doporučujeme, aby konfigurace s nasazením aplikace byla omezená na dvě oblasti.For disaster recovery, we recommend the configuration with application deployment limited to two regions. Je to proto, že většina geografických oblastí Azure má pouze dvě oblasti.This is because most of the Azure geographies have only two regions. Tato konfigurace nechrání vaši aplikaci před současným závažným selháním obou oblastí.This configuration does not protect your application from a simultaneous catastrophic failure of both regions. V nepravděpodobném případě takového selhání můžete databáze obnovit ve třetí oblasti pomocí operace geografického obnovení.In an unlikely event of such a failure, you can recover your databases in a third region using geo-restore operation.

Po zmírnění výpadku se sekundární databáze automaticky znovu synchronizuje s primárním.Once the outage is mitigated, the secondary database automatically resynchronizes with the primary. Během synchronizace může být ovlivněn výkon primární.During synchronization, performance of the primary can be impacted. Konkrétní dopad závisí na množství dat, které nově získal od převzetí služeb při selhání.The specific impact depends on the amount of data the new primary acquired since the failover. Následující diagram znázorňuje výpadek v sekundární oblasti:The following diagram illustrates an outage in the secondary region:

Scénář 1.

Hlavní výhodou tohoto vzoru návrhu jsou:The key advantages of this design pattern are:

  • Stejná webová aplikace se nasadí do obou oblastí bez jakékoli konfigurace specifické pro oblast a nevyžaduje další logiku pro správu převzetí služeb při selhání.The same web application is deployed to both regions without any region-specific configuration and doesn’t require additional logic to manage failover.
  • Výkon aplikace není ovlivněn převzetím služeb při selhání, protože webová aplikace a databáze jsou vždy umístěny společně.Application performance is not impacted by failover as the web application and the database are always co-located.

Hlavním kompromisem je, že prostředky aplikace v oblasti B jsou ve většině případů nevyužité.The main tradeoff is that the application resources in Region B are underutilized most of the time.

Scénář 2: oblasti Azure pro kontinuitu podnikových aplikací s maximálním uchováváním datScenario 2: Azure regions for business continuity with maximum data preservation

Tato možnost je vhodná pro aplikace s následujícími charakteristikami:This option is best suited for applications with the following characteristics:

  • Ztráta dat je vysokým obchodním rizikem.Any data loss is high business risk. Převzetí služeb při selhání databáze lze použít pouze jako poslední způsob, pokud je výpadek způsoben závažnou chybou.The database failover can only be used as a last resort if the outage is caused by a catastrophic failure.
  • Aplikace podporuje režimy operací jen pro čtení a čtení i zápis a v časovém intervalu může pracovat v režimu jen pro čtení.The application supports read-only and read-write modes of operations and can operate in "read-only mode" for a period of time.

V tomto modelu se aplikace přepne do režimu jen pro čtení, když se na začátku připojení pro čtení a zápis začnou získávat chyby časového limitu.In this pattern, the application switches to read-only mode when the read-write connections start getting time-out errors. Webová aplikace je nasazena v obou oblastech a zahrnuje připojení ke koncovému bodu naslouchacího procesu pro čtení i zápis a jiné připojení ke koncovému bodu naslouchacího procesu jen pro čtení (1).The Web Application is deployed to both regions and include a connection to the read-write listener endpoint and different connection to the read-only listener endpoint (1). Profil Traffic Manageru by měl používat Směrování priority.The Traffic manager profile should use priority routing. Pro koncový bod aplikace v každé oblasti (2) by mělo být povoleno monitorování koncových bodů .End point monitoring should be enabled for the application endpoint in each region (2).

Následující diagram znázorňuje tuto konfiguraci před výpadkem:The following diagram illustrates this configuration before an outage:

Scénář 2.

Když Traffic Manager zjistí selhání připojení v oblasti A, automaticky přepne provoz uživatele do instance aplikace v oblasti B. V tomto modelu je důležité nastavit období odkladu s ztrátou dat na dostatečně vysokou hodnotu, například 24 hodin.When the traffic manager detects a connectivity failure to region A, it automatically switches user traffic to the application instance in region B. With this pattern, it is important that you set the grace period with data loss to a sufficiently high value, for example 24 hours. Zajišťuje ztrátu dat, pokud dojde k omezení výpadku v této době.It ensures that data loss is prevented if the outage is mitigated within that time. Pokud je webová aplikace v oblasti B aktivována, operace čtení i zápisu se nedaří spustit.When the Web application in region B is activated the read-write operations start failing. V tomto okamžiku by měl přepnout do režimu jen pro čtení (1).At that point, it should switch to the read-only mode (1). V tomto režimu jsou požadavky automaticky směrovány do sekundární databáze.In this mode the requests are automatically routed to the secondary database. Pokud je výpadek způsoben závažnou chybou, pravděpodobně ho nelze zmírnit v období odkladu.If the outage is caused by a catastrophic failure, most likely it cannot be mitigated within the grace period. Po vypršení platnosti dojde k selhání skupiny převzetí služeb při selhání.When it expires the failover group triggers the failover. Po tom, co bude k dispozici naslouchací proces pro čtení i zápis a připojení k němu přestane selhat (2).After that the read-write listener becomes available and the connections to it stop failing (2). Následující diagram znázorňuje dvě fáze procesu obnovení.The following diagram illustrates the two stages of the recovery process.

Poznámka

Pokud dojde k zmírnění výpadku v primární oblasti v rámci období odkladu, Traffic Manager detekuje obnovení připojení v primární oblasti a přepne přenos uživatelů zpátky do instance aplikace v oblasti A. Instance aplikace bude pokračovat a funguje v režimu pro čtení i zápis pomocí primární databáze v oblasti A, jak je znázorněno v předchozím diagramu.If the outage in the primary region is mitigated within the grace period, traffic manager detects the restoration of connectivity in the primary region and switches user traffic back to the application instance in region A. That application instance resumes and operates in read-write mode using the primary database in region A as illustrated by the previous diagram.

Scénář 2.

Pokud dojde k výpadku v oblasti B, Traffic Manager zjistí selhání koncového bodu Web-App-2 v oblasti B a označí ho jako snížený (1).If an outage happens in region B, the traffic manager detects the failure of the end point web-app-2 in region B and marks it degraded (1). Mezitím skupina převzetí služeb při selhání přepne naslouchací proces jen pro čtení do oblasti A (2).In the meantime, the failover group switches the read-only listener to region A (2). Tento výpadek nemá vliv na činnost koncového uživatele, ale během výpadku se zveřejňuje primární databáze.This outage does not impact the end user experience but the primary database is exposed during the outage. Následující diagram znázorňuje selhání v sekundární oblasti:The following diagram illustrates a failure in the secondary region:

Scénář 2.

Po zmírnění výpadku je sekundární databáze hned synchronizována s primární databází a naslouchací proces jen pro čtení se přepne zpět do sekundární databáze v oblasti B. V závislosti na množství dat, které je třeba synchronizovat, může být během synchronizace na primárním počítači mírně ovlivněný výkon.Once the outage is mitigated, the secondary database is immediately synchronized with the primary and the read-only listener is switched back to the secondary database in region B. During synchronization performance of the primary could be slightly impacted depending on the amount of data that needs to be synchronized.

Tento vzor návrhu má několik výhod:This design pattern has several advantages:

  • Vyhne se ztrátě dat během dočasného výpadku.It avoids data loss during the temporary outages.
  • Výpadky závisí jenom na tom, jak rychle Traffic Manager detekuje selhání připojení, což je konfigurovatelné.Downtime depends only on how quickly traffic manager detects the connectivity failure, which is configurable.

Kompromisem je, že aplikace musí být schopná pracovat v režimu jen pro čtení.The tradeoff is that the application must be able to operate in read-only mode.

Scénář 3: přemístění aplikace na jinou geografickou oblast bez ztráty dat a téměř bez výpadkůScenario 3: Application relocation to a different geography without data loss and near zero downtime

V tomto scénáři má aplikace následující vlastnosti:In this scenario the application has the following characteristics:

  • Koncoví uživatelé přistupují k aplikaci z různých geografických oblastíThe end users access the application from different geographies
  • Tato aplikace zahrnuje úlohy jen pro čtení, které nezávisí na úplné synchronizaci s nejnovějšími aktualizacemi.The application includes read-only workloads that do not depend on full synchronization with the latest updates
  • Přístup pro zápis dat by měl být podporován ve stejné geografické oblasti pro většinu uživatelů.Write access to data should be supported in the same geography for majority of the users
  • Latence čtení je pro činnost koncového uživatele zásadní.Read latency is critical for the end user experience

Aby bylo možné splnit tyto požadavky, je třeba zaručit, že se zařízení uživatele vždy připojí k aplikaci nasazené ve stejné geografické oblasti pro operace jen pro čtení, například na data procházení, analýzy atd. Zatímco operace OLTP se zpracovávají ve stejné geografické oblasti.In order to meet these requirements you need to guarantee that the user device always connects to the application deployed in the same geography for the read-only operations, such as browsing data, analytics etc. Whereas, the OLTP operations are processed in the same geography most of the time. Například během dne se OLTP operace zpracování ve stejné geografické oblasti, ale v době mimo hodiny, kdy je možné je zpracovat v jiném geografickém období.For example, during the day time OLTP operations are processed in the same geography, but during the off hours they could be processed in a different geography. Pokud činnost koncového uživatele většinou probíhá během pracovní doby, můžete zajistit optimální výkon pro většinu uživatelů v většinu času.If the end user activity mostly happens during the working hours, you can guarantee the optimal performance for most of the users most of the time. Tato topologie je znázorněna na následujícím obrázku.The following diagram shows this topology.

Prostředky aplikace by se měly nasadit v každé geografické oblasti, kde máte významné nároky na využití.The application’s resources should be deployed in each geography where you have substantial usage demand. Například pokud se vaše aplikace aktivně používá v USA, Evropské unii a Jižní Východní Asie aplikace by měla být nasazená do všech těchto zeměpisných oblastí.For example, if your application is actively used in the United States, European Union and South East Asia the application should be deployed to all of these geographies. Primární databáze by se měla dynamicky přepínat mezi jednotlivými geografickými oblastmi na konci pracovní doby.The primary database should be dynamically switched from one geography to the next at the end of the working hours. Tato metoda se nazývá "následovat na Sun".This method is called “follow the sun”. Úloha OLTP se vždy připojuje k databázi prostřednictvím naslouchacího procesu pro čtení a zápis <převzetí služeb při selhání-název skupiny>. Database.Windows.NET (1).The OLTP workload always connects to the database via the read-write listener <failover-group-name>.database.windows.net (1). Úloha jen pro čtení se připojuje k místní databázi přímo pomocí koncového bodu serveru databáze <název serveru>. Database.Windows.NET (2).The read-only workload connects to the local database directly using the databases server endpoint <server-name>.database.windows.net (2). Traffic Manager je nakonfigurovaný pomocí metody směrování výkonu.Traffic manager is configured with the performance routing method. Zajišťuje, aby bylo zařízení koncového uživatele připojeno k webové službě v nejbližší oblasti.It ensures that the end user’s device is connected to the web service in the closest region. Traffic Manager by měl být nastaven s povoleným monitorováním koncových bodů pro každý koncový bod webové služby (3).Traffic manager should be set up with end point monitoring enabled for each web service end point (3).

Poznámka

Tato oblast se používá pro převzetí služeb při selhání konfigurace skupiny převzetí služeb při selhání.The failover group configuration defines which region is used for failover. Vzhledem k tomu, že nový primární objekt je v jiné geografické úrovni, jsou výsledky převzetí služeb při selhání v delší době pro OLTP i pro úlohy jen pro čtení, dokud se ovlivněná oblast znovu nevrátí do režimu online.Because the new primary is in a different geography the failover results in longer latency for both OLTP and read-only workloads until the impacted region is back online.

Scénář 3.

Na konci dne (například v místním čase 23:00) by měly být aktivní databáze přepnuty do další oblasti (Severní Evropa).At the end of the day (for example at 11PM local time) the active databases should be switched to the next region (North Europe). Tato úloha se dá plně automatizovat pomocí služby plánování Azure.This task can be fully automated by using Azure scheduling service. Úkol zahrnuje následující kroky:The task involves the following steps:

  • Přepnutí primárního serveru ve skupině převzetí služeb při selhání na Severní Evropa s použitím popisného převzetí služeb při selhání (1Switch primary server in the failover group to North Europe using friendly failover (1)
  • Odebrání skupiny převzetí služeb při selhání mezi Východní USA a Severní EvropaRemove the failover group between East US and North Europe
  • Vytvoří novou skupinu převzetí služeb při selhání se stejným názvem, ale mezi Severní Evropa a Východní Asie (2).Create a new failover group with the same name but between North Europe and East Asia (2).
  • Do této skupiny převzetí služeb při selhání přidejte primární Severní Evropa a sekundární Východní Asie.Add the primary in North Europe and secondary in East Asia to this failover group (3).

Následující diagram znázorňuje novou konfiguraci po plánovaném převzetí služeb při selhání:The following diagram illustrates the new configuration after the planned failover:

Scénář 3.

Pokud dojde k výpadku v Severní Evropa například automatické převzetí služeb při selhání databáze je iniciováno skupinou převzetí služeb při selhání, což efektivně vede k přesunu aplikace do další oblasti před plánem (1).If an outage happens in North Europe for example, the automatic database failover is initiated by the failover group, which effectively results in moving the application to the next region ahead of schedule (1). V takovém případě je USA – východ jedinou zbývající sekundární oblastí, dokud Severní Evropa znovu nepřejdete do režimu online.In that case the US East is the only remaining secondary region until North Europe is back online. Zbývající dvě oblasti slouží zákazníkům ve všech třech zeměpisných oblastech přepínáním rolí.The remaining two regions serve the customers in all three geographies by switching roles. Plánovač Azure je potřeba upravit odpovídajícím způsobem.Azure scheduler has to be adjusted accordingly. Vzhledem k tomu, že zbývající oblasti získají další uživatelský provoz z Evropy, výkon aplikace bude mít vliv nejen na další latenci, ale také na zvýšený počet připojení koncových uživatelů.Because the remaining regions get additional user traffic from Europe, the application's performance is impacted not only by additional latency but also by an increased number of end user connections. Po omezení výpadku v Severní Evropa je sekundární databáze okamžitě synchronizovaná s aktuální primární databází.Once the outage is mitigated in North Europe, the secondary database there is immediately synchronized with the current primary. Následující diagram znázorňuje výpadek Severní Evropa:The following diagram illustrates an outage in North Europe:

Scénář 3.

Poznámka

Můžete zkrátit čas, kdy se činnost koncového uživatele v Evropě sníží o dlouhou latenci.You can reduce the time when the end user’s experience in Europe is degraded by the long latency. K tomu byste měli proaktivně nasadit kopii aplikace a vytvořit sekundární databáze v jiné místní oblasti (Západní Evropa) jako náhradu offline instance aplikace v Severní Evropa.To do that you should proactively deploy an application copy and create the secondary database(s) in another local region (West Europe) as a replacement of the offline application instance in North Europe. Když je znovu online, můžete se rozhodnout, jestli chcete i nadále používat Západní Evropa nebo odebrat kopii aplikace a přepnout zpátky na použití Severní Evropa.When the latter is back online you can decide whether to continue using West Europe or to remove the copy of the application there and switch back to using North Europe.

Klíčové výhody tohoto návrhu:The key benefits of this design are:

  • Úloha aplikace jen pro čtení přistupuje k datům v oblasti skříní.The read-only application workload accesses data in the closets region at all times.
  • Úloha čtení a zápisu aplikací přistupuje k datům v nejbližší oblasti během období nejvyšší aktivity v jednotlivých geografických oblastech.The read-write application workload accesses data in the closest region during the period of the highest activity in each geography
  • Vzhledem k tomu, že aplikace je nasazena do více oblastí, může dojít ke ztrátě jedné z oblastí bez jakéhokoli významného výpadku.Because the application is deployed to multiple regions, it can survive a loss of one of the regions without any significant downtime.

Existují však některé kompromisy:But there are some tradeoffs:

  • Oblastní výpadek má za následek, že by to ovlivnilo delší latenci.A regional outage results in the geography to be impacted by longer latency. Aplikace v jiném geografickém programu obsluhuje pouze úlohy pro čtení i zápis i pro čtení.Both read-write and read-only workloads is served by the application in a different geography.
  • Úlohy jen pro čtení se musí připojit k jinému koncovému bodu v každé oblasti.The read-only workloads must connect to a different end point in each region.

Plánování kontinuity podnikových aplikací: volba návrhu aplikace pro zotavení po havárii v clouduBusiness continuity planning: Choose an application design for cloud disaster recovery

Vaše konkrétní strategie cloudového zotavení po havárii může tyto vzory návrhu zkombinovat nebo roztáhnout tak, aby co nejlépe splňovala požadavky vaší aplikace.Your specific cloud disaster recovery strategy can combine or extend these design patterns to best meet the needs of your application. Jak už bylo zmíněno dříve, strategie, kterou zvolíte, je založená na smlouvě SLA, kterou chcete nabídnout vašim zákazníkům a topologii nasazení aplikace.As mentioned earlier, the strategy you choose is based on the SLA you want to offer to your customers and the application deployment topology. Následující tabulka porovnává tyto možnosti podle rozhodnutí bodu obnovení (RPO) a odhadované doby obnovení (ERT), které vám pomůžou s vaším rozhodnutím.To help guide your decision, the following table compares the choices based on recovery point objective (RPO) and estimated recovery time (ERT).

VzorPattern OBNOVENÍRPO ERTERT
Aktivní – pasivní nasazení pro zotavení po havárii s společně umístěným přístupem k databáziActive-passive deployment for disaster recovery with co-located database access Přístup pro čtení i zápis < 5 secRead-write access < 5 sec Čas detekce selhání + hodnota TTL systému DNSFailure detection time + DNS TTL
Aktivní – aktivní nasazení pro vyrovnávání zatížení aplikaceActive-active deployment for application load balancing Přístup pro čtení i zápis < 5 secRead-write access < 5 sec Čas detekce selhání + hodnota TTL systému DNSFailure detection time + DNS TTL
Aktivní – pasivní nasazení pro zachování datActive-passive deployment for data preservation Přístup jen pro čtení < 5 secRead-only access < 5 sec Přístup jen pro čtení = 0Read-only access = 0
Přístup pro čtení i zápis = nulaRead-write access = zero Přístup pro čtení i zápis = doba detekce selhání + období odkladu s ztrátou datRead-write access = Failure detection time + grace period with data loss

Další krokyNext steps