ZhSla

A VIK Wikiből
A lap korábbi változatát látod, amilyen (vitalap) 2012. október 22., 10:51-kor történt szerkesztése után volt. (Új oldal, tartalma: „{{GlobalTemplate|Infoszak|ZhSla}} ===Milyen szempontok alapján válasszunk service level objective paramétereket? === * Significance ** “service level paramete…”)
(eltér) ← Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)
Ugrás a navigációhoz Ugrás a kereséshez

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót


Milyen szempontok alapján válasszunk service level objective paramétereket?

  • Significance
    • “service level parameters should be articulated in terms of the particular service itself and should be applied at the same layer of the communications stack rather than a layer or two further down”
    • service level parameters are closely related to actual end-user concerns of the provided service and involve much more than network-performance parameters such as network delay and jitter
  • Relevance
    • csak a valóban fontos paraméterek, mert ezeket a paramétereket mérni is kell majd, hogy igazolni tudjuk a szerződés teljesítését
    • Important enough
      • Too many parameters
        • Must be monitored!!!
    • Non factor params
  • Measurability
    • Goal of SLA
      • Clear and measurable definition of acceptable service
      • Cost of measurements
    • Azt is rögzíteni kell, hogy mi lesz a mérési módszer, hogyan mérünk.
  • Voice Service Example
    • Dial tone time
    • End-to-end delay
    • Call completion rate
    • Busy hour call attempts (BHCA)
    • Ring tone
    • Average mean opinion score (MOS)
    • Availability in peak and off-hours
    • (New) user provisioning (add/delete/move)

ToDo kép az SLO levelekről

Mik azok az SLA-k? Kik, miért és mire használják ezeket?

SLA: Service Level Agreement

Az SLA egy szerződés valamilyen szolgáltatás nyújtásáról. Specialitása, hogy rögzítik benne, hogy a nyújtott szolgáltatás szintjét, minőségét milyen paramétereken keresztül milyen mérési módszerrel mérjük, mi az elvárt szint és mi a büntetés, ha a szolgáltatás nem éri el a szerződésben kikötött szintet.

Service level objectives (SLO)

  • Parameters and target values

Nontechnical aspects

  • What happens if objectives are not met

Ki köt ilyen szerződést?

  • Every service provider for every customer
    • But boilerplate specs for residential customers
    • Others made on demand

Mit tartalmaz es jó SLA?

  • a mért paramétereket
  • mennyi az elvárt szintje a paraméternek
  • mi a büntetés, ha a szolgáltató nem tudja teljesíteni a vállalását
  • ki méri az adott paramétert
  • milyen mérési módszerrel
  • What will be delivered == service level objectives (SLO)
  • How to track and verify?
  • What if not delivered?
  • SLO/ Customer perspective
    • What is needed / critical?
    • Qualifications (e.g. time)

ToDo ábra

  • SLO / Provider perspective
    • Maintenance and upgrades
    • Definition of terms
    • Assumptions (e.g. call holding times)
    • Realistic SLAs
    • TRUST relationship!!!

Milyen szempontokat kell figyelembe vennie egy szolgáltatónak, ha SLA megfelelésnek megfeleően szeretné a hálózatát és szolgáltatásait működtetni?

Managing for Service Level

  • Set-up
    • Reserve resources for SLAs
      • Dimensioning problem
        • Decomposition helps
        • Peak resource reservation
        • Statistical guarantees
          • Cost advantages can be shared with customer
    • Oversubscription Risks
      • Users might not be independent
      • Re-Provisioning
      • Admission control
  • Monitor
    • Source: Mgmt information
      • SNMP MIBs
      • Syslog
      • NetFlow and IPFIX
      • But are not directly available
        • N.B: Decomposition
    • Passive measurements
    • Active measurements
      • ICMP ping
    • Service level forecasts
      • trend analysis
      • Anomaly detections
        • Historic data & pattern (footprint)
    • Very good tools are
      • Threshold-crossing alerts
      • RMON-MIB to monitor any MIB variable
  • Statistic and proofs for delivery
    • Important as a proof of service
      • Fingerpointing data
      • To back up claim
    • Sometimes service level report are part of the service package
    • Back to statistics:
      • relevant? How the measurement were done?
      • Data authentic?

-- Böbe - 2012.03.13.