none
Reporting Services 2012, AlwaysOn, Best Practice ? RRS feed

  • Frage

  • Hallo,

    gibt es einen Best Practice für Reporting Services in einer AlwaysOn-Umgebung (2012) ?

    Meine "Architektur" ist eine AlwaysOn-Verfügbarkeitsgruppe innerhalb SQL Server (also keine AlwaysOn-FailoverClusterinstanz). Die Anwendung verlangt höchste Verfügbarkeit, also synchroner Modus und automatisch Failover ! Und so möchte ich eigentlich auch die Reporting Services konfigurieren. Also kann ich bzw. macht es Sinn, beide Rep.-Datenbank auf dem sekundären Node mit NoRecovery zu restoren  und im Read_Only Modus zu fahren ?  

    Gruß, ALexander

    Mittwoch, 21. Januar 2015 20:25

Antworten

  • Hallo Alexander,

    "höchste Verfügbarkeit" ist sicherlich auch relativ, oder? Mit 4 Neunen (99,99) wird es sehr schwierig in so einer Architektur. Da solltet Ihr eher ein Scale-Out und einen Network-Balancer in die Architektur aufnehmen.

    Reporting Service funktionieren zwar mittlerweile mit AlwaysOn Verfügbarkeitsgruppen, aber sie benötigen nach einem Failover noch einen zusätzlichen Service-Restart. Auch wenn dieser vielleicht nur 40 Sekunden dauert, sollte man das mit berücksichtigen.

    Ansonsten: Ja, beide Datenbanken müssen auf allen Knoten als Replikas verfügbar sein.

    Read_Only Modus macht in diesem Zusammenhang jedoch eher weniger Sinn, es sei DENN, es geht tatsächlich um eine Scale-Out Architektur mit verschiedenen Report-Servern, von denen jeweils einer die Verwaltung innehat.

    Für ein reguläres Failover der AG ist das nicht erforderlich, und normale Clients connecten sich auch nicht mit diesen Datenbanken.

    Hier kannst Du zum Weiterlesen einsteigen:Reporting Services with AlwaysOn Availability Groups


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 23. Januar 2015 16:04

Alle Antworten

  • Hallo Alexander,

    "höchste Verfügbarkeit" ist sicherlich auch relativ, oder? Mit 4 Neunen (99,99) wird es sehr schwierig in so einer Architektur. Da solltet Ihr eher ein Scale-Out und einen Network-Balancer in die Architektur aufnehmen.

    Reporting Service funktionieren zwar mittlerweile mit AlwaysOn Verfügbarkeitsgruppen, aber sie benötigen nach einem Failover noch einen zusätzlichen Service-Restart. Auch wenn dieser vielleicht nur 40 Sekunden dauert, sollte man das mit berücksichtigen.

    Ansonsten: Ja, beide Datenbanken müssen auf allen Knoten als Replikas verfügbar sein.

    Read_Only Modus macht in diesem Zusammenhang jedoch eher weniger Sinn, es sei DENN, es geht tatsächlich um eine Scale-Out Architektur mit verschiedenen Report-Servern, von denen jeweils einer die Verwaltung innehat.

    Für ein reguläres Failover der AG ist das nicht erforderlich, und normale Clients connecten sich auch nicht mit diesen Datenbanken.

    Hier kannst Du zum Weiterlesen einsteigen:Reporting Services with AlwaysOn Availability Groups


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 23. Januar 2015 16:04
  • Hallo Andreas,

    Read_Only war ein Denkfehler -)

    Die Datenbanken hab' ich inzwischen auf beiden Seiten syncron und das läuft auch stabil, wobei noch nicht viel passiert in der Umgebung....

    Die höchste Verfügbarkeit bezog sich auf die reine AlwaysOn-Architektur in einem 2-Node-Windows-Cluster und das ist sicherlich etwas weniger als die 4 Neune -)

    Was meinst du mit Service-Restart ? Also ich muß den Reporting-Service restarten, obwohl er läuft ?

    Die angegebene Seite kenne ich.

    Danke.

    Dienstag, 27. Januar 2015 12:39
  • ...

    Was meinst du mit Service-Restart ? Also ich muß den Reporting-Service restarten, obwohl er läuft ?

    ...

    Genau. Nach einem Failover musst Du die SSRS-Services einmal neu starten, damit die Verbindung mit dem Neuen Primary läuft. Das steht auf der oben verlinkten Seite unter "Steps to complete disaster recovery of Report Server Databases" auch beschrieben ;-)

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Dienstag, 27. Januar 2015 12:54
  • Hallo,

    ich muß hier noch eine Anmerkung machen :

    Die Datenbanken auf dem sekondären Node sind doch immer (höchstens) read_only ! Das meinte ich damit....

    Gruß,

    ALexander

    Donnerstag, 12. Februar 2015 09:41
  • Hallo,

    ich muß hier noch eine Anmerkung machen :

    Die Datenbanken auf dem sekondären Node sind doch immer (höchstens) read_only ! Das meinte ich damit....

    Gruß,

    ALexander

    Wenn Du das "höchstens" aus der Klammer entfernst, und am Besten noch dick schreibst, dann gehe ich da 100% mit :)

    Denn "immer" sind sie ja nicht read_only - aus gutem Grunde, da es ja Geld und durchaus auch Performance kosten kann :)


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Donnerstag, 12. Februar 2015 09:48