Tervezés használatoptimalizáláshoz

Befejeződött
Az erőforrások és műveletek használatának maximalizálása. Alkalmazza őket a megoldás egyeztetett funkcionális és nem funkcionális követelményeire.

A szolgáltatások és ajánlatok különböző képességeket és tarifacsomagokat biztosítanak. Miután megvásárolta a funkciók egy készletét, kerülje az alulhasználatot. A rétegbeli befektetés maximalizálásának módjai. Hasonlóképpen, folyamatosan értékelje ki a számlázási modelleket, hogy megtalálja azokat, amelyek jobban igazodnak a használathoz az aktuális éles számítási feladatok alapján.

Példaforgatókönyv

A Contoso Egyetem jelenleg egy kereskedelmi célú, polcon kívüli (COTS) megoldást üzemeltet, amely lehetővé teszi az egyetemi oktatók számára a tanévre vonatkozó kurzusok létrehozását és frissítését, és ez az elsődleges regisztrációs portál, amelyet a diákok használnak ezekhez a kurzusokhoz. A megoldás egyéni integrációval rendelkezik egy szolgáltatott szoftver (SaaS) oktatási felügyeleti rendszerrel, amely reményei szerint néhány év múlva az összes funkciójukat áttelepítik. Addig is optimalizálni szeretnék az egyéni integrációs összetevők költségeit.

A COTS-ajánlat technológiai megoldását általában fekete dobozként kezelik, kivéve annak adatbázisát, amely az Azure Database for MySQL. Az egyéni integráció egy Azure Durable Függvény, amely egy standard szolgáltatási csomagon fut Azure-alkalmazás Szolgáltatásban. Ez az App Service korábban egy egyetemi webhelyet üzemeltetett, de ez már nem így van. Ez a tartós függvény egy dedikált Azure Storage-fiók által támogatott Python-alkalmazás, amely éjszakai szinkronizálást végez a MySQL-adatbázisból az SaaS API-ba.

Használatalapú díjszabás használata gyakorlatiasság esetén

Lehetnek olyan szolgáltatások, amelyek fogyasztásalapú díjszabást kínálnak, ami azt jelenti, hogy csak a szolgáltatás kihasználtságáért kell fizetnie, és leállíthatja a szolgáltatást, ha nincs szükség a költségek leállítására. Ha olyan számítási feladat-összetevőkkel rendelkezik, amelyek csak szórványosan vannak használatban, ez segíthet minimalizálni az elpazarolt költségeket az összetevő 24/7/365-ös futtatásának kifizetésével összehasonlítva.

A fogyasztásalapú díjszabás használatával csak a használatért kell fizetnie. Ez a lehetőség akkor jó választás, ha a számítási feladatok számítása várhatóan nem lesz teljes munkaidőben kihasználva.

A Contoso kihívása

  • A szinkronizálási feladat általában körülbelül egy órán át fut minden éjjel, egy adott időpontban. A teljesítménye történelmileg kielégítő volt. A hibák ritkán fordulnak elő, és az átmeneti hibák jól kezelhetők a jelenlegi konfigurációban.
  • Mivel a szinkronizálási feladathoz szükséges számítás naponta csak egy órát használ, és a kihasználtságtól függetlenül 24 órát fizetnek, a számítási feladatért felelős csapat az aktuális kialakítás alternatívát keres.
  • A csapat fontolóra vette egy szkript írását a szolgáltatás leállításához minden este a szinkronizálás futtatása és a következő nap ismételt üzembe helyezése után, de ez a megoldás nagy kockázattal és összetettséggel járna.

A megközelítés és az eredmények alkalmazása

  • A csapat elemzi a feladatelőzményeket, és azt tapasztalják, hogy a függvény eddigi leghosszabb futtatása alig két óra alatt történt. Összehasonlítják a dedikált csomag költségeit az Azure Functions-használati terv költségével a legrosszabb esetben, és arra a következtetésre jutnak, hogy a fogyasztási csomag olcsóbb lesz.
  • A csapat teljesítménytesztet futtat annak biztosítása érdekében, hogy a teljesítmény elegendő legyen, és a futási idő enyhe növekedését észlelik, de ez még mindig elfogadható korlátokon belül van.
  • A számítási feladat teljes költsége a használati terv használatával csökken, mivel csak a feladat végrehajtásakor merülnek fel költségek.

A magas rendelkezésre állású kialakítás optimalizálása

Rangsorolja az aktív-aktív vagy csak aktív-csak aktív-passzív modellek üzembe helyezését a helyreállítási terv részeként, ha már kifizette az erőforrásokat.

Ha a tervezés alapértelmezés szerint aktív-passzív modelleket használ, előfordulhat, hogy üresjárati erőforrásokkal rendelkezik, amelyeket egyébként használhat. Az aktív-aktívvá alakítás lehetővé teszi, hogy túlterhelés nélkül megfeleljen a terheléskiegyenlítési és skálázási követelményeknek. Ha csak aktív modellel tudja teljesíteni a helyreállítási célokat, az erőforrások költségei teljesen el lesznek távolítva.

A Contoso kihívása

  • A COTS-alkalmazás rugalmas Azure Database for MySQL-kiszolgálót használ ugyanazon zóna magas rendelkezésre állására konfigurálva, amely egy készenléti kiszolgálót biztosít az elsődleges kiszolgálóval azonos rendelkezésre állási zónában. Emellett engedélyezték az automatikus biztonsági mentéseket is.
  • A számítási feladat RPO-jának hossza viszonylag hosszú, 12 óra, az RTO pedig három óra az iskolai nap folyamán.
  • A korábbi helyreállítási tesztek alapján a csapat tudja, hogy az RPO- és RTO-célokat a készenléti kiszolgálóra való automatikus feladatátvétellel teljesíteni tudják. Azt is tesztelték, hogy helyreállítják az adatbázist egy biztonsági másolatból, és megfelelnek az ebben a forgatókönyvben szereplő céloknak.

A megközelítés és az eredmények alkalmazása

  • A számítási feladatokkal foglalkozó csapat újraértékeli a magas rendelkezésre állási kialakítás előnyeit, és a szolgáltatás költsége kétszer akkora, mint egyetlen példány.
  • A csapat teszteli az új példány létrehozásának és az adatbázis biztonsági mentésből való helyreállításának tesztelését, és elégedettek azzal, hogy továbbra is megfelelnek a helyreállítási céloknak, ezért úgy döntenek, hogy megszüntetik a készenléti példányt.
  • A csapat frissíti a dr. tervet, hogy tükrözze az új helyreállítási stratégiát, és az új konfiguráción keresztül megvalósítsa a költségmegtakarítást.

A felhőkörnyezet tisztán tartása a nem használt erőforrásoktól és adatoktól

Rendszeresen és szigorúan felülvizsgálja a nem használt erőforrások és adatok üzembe helyezését és leszerelését. A korábban valamilyen célra szükséges, de már nem használt erőforrások és adatok idővel a felhőkörnyezetekben is tovább halmozódnak, és szükségtelenül felmerülnek a költségek. Ügyeljen arra, hogy a környezetek tisztán maradjanak a költséghatékonyság optimalizálása érdekében.

A fel nem használt erőforrások leállítása és az adatok törlése, ha már nincs rá szüksége, csökkenti a hulladékot, és felszabadítja a forrásokat, hogy máshol is be tudja fektetni őket.

A Contoso kihívása

  • Az egyetem történelmileg konzervatív megközelítést alkalmazott a leszerelési megoldásokra, attól tartva, hogy előfordulhat, hogy vissza kell térniük egy korábbi konfigurációra. Ez az óvatosság azt eredményezte, hogy a szolgáltatások egy vagy több környezetben futnak hónapokig, amelyekről bizonyos esetekben megfeledkeztek.
  • Ha elhagyatott szolgáltatásokat fedeznek fel, az általában véletlenül történik, mivel nincs hivatalos eljárás az ilyen szolgáltatások környezetének felülvizsgálatára.

A megközelítés és az eredmények alkalmazása

  • A csapat hozzáadja az App Service leszerelését a hátralékhoz az App Service-ből a Durable függvény használatba vett tárhelyére való migrálás részeként. A következő futam részeként minden környezetben leállítják az App Service üzemelő példányait.
  • Az elhagyott erőforrások proaktív észlelésének elősegítése érdekében a csapat riasztásokat állít be az Azure Advisorban, hogy értesítse őket a fel nem használt erőforrásokról.
  • A csapat egy új szabályzatot implementál, amely megköveteli a csapattól, hogy havonta teljes körűen tekintse át az éles környezeteket, és negyedévente teljes áttekintést adjon az éles környezetről az elhagyott erőforrások azonosítása érdekében. A felhagyott erőforrásokat a rendszer hozzáadja a leállítási teendőlistához.

Tesztelje tudását

1.

Ezek közül melyik érhető el bizonyos Azure számítási szolgáltatások esetében, hogy pénzt takarítson meg azzal, hogy csak a használt számításért fizet?

2.

Az alábbi HA-tervek közül melyiket érdemes elkerülnie a költséghatékonyság érdekében, ha már kifizette az erőforrásokat?

3.

Mi az egyik módja annak, hogy a számítási feladatok csapata biztosítsa, hogy elfogják az elhagyott erőforrásokat, például a már nem használt MySQL-kiszolgálókat?