Auteur Sujet: Panne électrique majeure chez OVH (sites inacessibles)  (Lu 3978 fois)

0 Membres et 1 Invité sur ce sujet

ldrevon

  • AS43142 Officiel Adeli
  • Expert
  • *
  • Messages: 607
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #108 le: 15 novembre 2017 à 14:23:28 »
En fait moi non plus, meme un laptop ne redémarre pas eu une minute...
J'ai trouvé un server HP-UX avec 2100 jours de uptime sans reboot dans un DC, un record  :D
On en a qui reboot en moins d'une minute et il est vrai qu'on en a d'autre qui reboot en 5mn!
Je vous ferai une  vidéo. (promis)
Le raid au reboot on s'en fout (à part si un disque est mort  et c'est un autre sujet), ton serveur est censé redémarrer en mode bancal sinon c'est un mauvais choix de carte/serveur.
Le seul "point" c'est le système de fichier donc exit le ext2/3/4 qui te demande de valider le check...
Si ton serveur ne supporte pas le reboot hard c'est qu'il est trop vieux  et que si cela impact ta prod tu vires le DSI (ou tu te mets des baffes si tu n'as personne à "violenter" sous la main)
A chaque pbm une solution


miky01

  • Expert. Réseau RESO-LIAin (01)
  • Client K-Net
  • *
  • Messages: 2 990
  • FTTH 100 Mb/s sur Farges (01)
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #109 le: 15 novembre 2017 à 15:45:10 »
Tu as raison, mais il faut pas oublier que le matos Tres Haute Dispo, comme les bays de disc SAN Hitachi, les HP aussi, les EMC je sais pas, ca se reboot JAMAIS, sauf en cas de déménagement ou arret definitif...

Il y a une procédure de shudown a respecter, assez longue, pour pouvoir la redemarer sans crash, dans le cas que je cite, "Emergency power OFF", tu coupe le jus dans toute la salle, UPS, diesel   inclus, (c'est une exigence des assurances), et je t'assure que tu peux plus la redemarrer, faut faire venir l'ingénieur de support pour suivre une procédure tres complexe qui prend plusieurs heures.

joli!  ;D

ne pas mettre le champignon trop proche des portes la prochaine fois + gros panneau rouge clignotant ne pas toucher ^^

Ben ca servi de lecon, le champignon est maintenant dans une box ou faut casser la vitre pour appuyer dessus, et autre dommage colatéral, le serveur qui gère les badges d'acces / controle empreinte etait mort, donc impossible de quitter ou entrer dans le DC , ils ont mis une clé pour ouverture manuelle a coté du champignon, ca aurais pu etre dramatique si c'était l'extinction Co2 qui se déclanchée et que le gas peux plus sortir  ;D

xp25

  • Client Orange Fibre
  • *
  • Messages: 167
  • Villeurbanne (69)
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #110 le: 15 novembre 2017 à 16:42:02 »
Il y a les pros, les vrais et les baltringues, escrocs, voyous etc.

Un DC ne doit jamais être down (sauf déménagement et encore les routeurs de re-reroutage vers nouveau site non durant 2 mois).
C'est depuis que certains l'on été que c'est devenu normal et que ça passe comme fait divers.

Tout les serveurs et switch/routeurs de collecte ont mini une double alimentation qui doit être sécurisée sur des onduleurs différents et redondants en N+2.

L'alimentation de secours par générateur intervient dès que les onduleurs N+1 sont en passe de basculer sur N+2.

Un hébergement sécurisé pour sites sensibles doit être en auto replication dans un autre site avec un re-routage par 2 liens différents et activé automatiquement en cas de saut des onduleurs N+1.

En cas d'incendie, la salle doit être évacué et le feu étouffé selon les normes par dispersion de gaz à privation d'oxygène et en aucun cas une coupure électrique ne doit s'effectuer de l'intérieur de la salle et sans avis d'un professionnel du feu.

Et je ne parle pas de la séparation de l'alimentation électrique et réseau du système de gestion de l'infrastructure du bâtiment entier (générateur et onduleurs inclus).

Alors oui ça coûte de l'argent mais un professionnel ne mange pas du riz à vie parce qu'il propose de l'hébergement de cette qualité.

vivien

  • Administrateur
  • *
  • Messages: 27 071
    • Twitter LaFibre.info
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #111 le: 15 novembre 2017 à 16:43:42 »
Ben ca servi de lecon, le champignon est maintenant dans une box ou faut casser la vitre pour appuyer dessus, et autre dommage colatéral, le serveur qui gère les badges d'acces / controle empreinte etait mort, donc impossible de quitter ou entrer dans le DC , ils ont mis une clé pour ouverture manuelle a coté du champignon, ca aurais pu etre dramatique si c'était l'extinction Co2 qui se déclanchée et que le gas peux plus sortir  ;D
Il faut badger pour sortir de la salle ? C'est pas illégal si il n'y a pas de sortie de secours ?

Je n'ai jamais vu ça sauf certains datacenter équipé de sans unipersonnel. Tu badge en entrée en et en sortie, cela permet d'être sur que tu ne prête pas ton badge pour faire rentrer une seconde personne (car il est impossible de rentrer tant que tu n'est pas sorti)
3Dans ces cas là, il y a bien sur une sorite d'urgence via une porte, située a coté du sas unipersonnel. Tu actionne la porte par un bouton poussoir en cas d'urgence et la sécurité est prévenue.

octal

  • Client Free adsl
  • *
  • Messages: 1 509
  • Paris (75)
    • Georges Clémenceau: »La France est un pays fertile, on y plante des fonctionnaires, il y pousse des impôts »
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #112 le: 15 novembre 2017 à 17:11:08 »
Les règles de l'art sont au Archives Nationale  ;D

miky01

  • Expert. Réseau RESO-LIAin (01)
  • Client K-Net
  • *
  • Messages: 2 990
  • FTTH 100 Mb/s sur Farges (01)
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #113 le: 15 novembre 2017 à 17:19:09 »
Ben c'est le cas , en entrée tu badge et tu mets ton index sur le detecteur, en sortie seuelement le badge (RFID) , et c'est pas une porte mais un sas, qui en plus controle le poid (pour pas que tu passe a deux dans le sas), alors si tu as un gros carton CISCO de 30 Kg tu es pas dans la merde... faut demander au garde de t'ouvrir le sas.

Meme les assenseurs te laisse aller que la l'étage ou tu as les droits sur ton badge.

Le systeme compte les entrées et sorties, si tu entre et tu passe ton badge a un autre, ben ca marche pas, pas la bonne emprinte, et considéreé comme a l'intérieur... T'as la sécurité qui te tombe dessus.

Maintenant , il a bien sur une sortie de secour, (c'est une obligation) avec poignée plombée (comme les compteur EDF) , mais si tu sort par la tu fais hurler l'alarme du batiment, donc jamais personne s'y risque, et en plus tu peux plus etre identififé pour re-entrer par le sas.

Je supose que chez OVH ca doit etre plus "light", comme la redondance  ;)
mais les prix sont pas les meme...

Et pour cerains clients qui loue des salles, les racks tres sensble sont verouillés par électroaiment, il faut l'authorisation de l'IT manager de la société pour y acceder, ca peux prendre 2 heures avant que tu arrive a la fibre que tu dois remplacer,

Mais bon quand c'est de secret de fabrications qui sont sur les serveurs, ca se comprend, et tu ressort pas avec un disque mort, il reste dans la salle et est détruit par une equipe qui fait ca.

benoit75015

  • Client Free adsl
  • *
  • Messages: 265
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #114 le: 16 novembre 2017 à 10:58:50 »
Nouvel incident, de nombreux liens sont down sur TH2 :

Nico

  • Modérateur
  • *
  • Messages: 28 697
  • FTTH 300Mbps sur Paris 15ème (75)
    • @_GaLaK_
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #115 le: 16 novembre 2017 à 11:04:48 »
Quel est l'impact en dehors de la weathermap ?

Optix

  • AS203679 NEWSOO
  • Expert
  • *
  • Messages: 564
  • Strasbourg (67)
    • Newsoo
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #116 le: 16 novembre 2017 à 11:04:53 »

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 3 836
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #117 le: Hier à 06:55:57 »
Voici un nouveau compte rendu encore plus détaillé de la part d'OVH vsur l'incident majeur de Strasbourg.
http://travaux.ovh.net/?do=details&id=28247

Ce que je retiens:
* L'automate inverseur de source, qui démarre aussi les groupes (?), était dans un mode défaut. Or, ce mode défaut aurait du être remonté, et détecté. Est-ce qu'il était en défaut avant l'incident? L'histoire ne le dit pas.
* Ce même automate n'est apparemment pas redondé. C'est difficilement compréhensible pour moi. C'est "assez facile" de redonder un automate au moins pour la partie "démarrage d'un groupe électrogène". L'ordre de démarrage d'un groupe, c'est en général simplement la fermeture d'un relais, donc facile à redonder.
* L'inverseur de source HT est-il lui même redondé? Peut-être pas, difficile à dire. Il y a 1 seul ou plusieurs bus-bar HT? Pareil, pas de détails.
* Un des groupes électrogènes était en maintenance, inutilisable. Et on comprend avec tout le reste, que la redondance des groupes n'était plus assurée. C'est malheureusement assez classique : beaucoup de datacenter en N+1 perdent la redondance lors de maintenance. Dans les datacenter critiques que je connais avec une telle archi N+1, on fait impérativement venir un groupe électrogène mobile provisoire (20 tonnes le bébé), en cas de grosse maintenance qui immobilise un groupe électrogène. De plus, certaines maintenances sont réalisables "à chaud", sans désactiver le groupe. Pareil pour les grosses maintenances de transfo, on remplace le transfo par un groupe électrogène.
* Les 2 groupes électrogènes HT n'ont pas réussi à se synchroniser (en HT), on n'a pas plus de détail.
* Le mélange entre une partie de l'architecture électrique en HT (20 000V) et l'autre en BT (380V) me semble assez tordu. Il y a des groupes HT et d'autres BT. Je ne comprends pas l'intérêt, mais c'est sans doute des choix techniques "historiques" qui ont amené à cette situation bizarre. Il est fort possible que le réseau HT interne constitue un SPOF, mais nous n'avons pas les détails.
* Les temps de rétablissement des différents services me paraissent très longs. 10h après que l'alimentation électrique soit revenue, beaucoup de services sont encore HS (20% des vCenters du private cloud). Mais je ne suis pas du métier, donc difficile de juger.

En tout cas, bravo à OVH pour la transparence.

Leon.

vivien

  • Administrateur
  • *
  • Messages: 27 071
    • Twitter LaFibre.info
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #118 le: Hier à 11:23:50 »
On a beaucoup parlé de l’ordre de démarrage des groupes haute tension (HT) qui n’avait pas été envoyé par l’automate pilotant l’inverseur. En fait il aurait l'envoyé l'ordre cela n'aurait rien changé ! Même panne pour la même durée, vu qu'en lés démarrant manuellement, ils n'ont pas réussi à faire passer le datacenter sur groupe.

Comme les 2 groupes électrogènes HT ne sont pas parvenus à se synchroniser, nous avons alors découplé les 2 groupes électrogènes HT pour les faire fonctionner séparèment. Un groupe seul délivrant uniquement 2MVA ne peut tenir la charge demandée et il s’arrête. Nous avons effectué de multiples essais dans différentes configurations, sans succès.

Si j'ai bien compris, Les 2 groupes électrogènes HT (20 000 volts) protègent les 3 datanceter de Strasbourg (SBG1, SBG4 et SBG2).
Par contre seul SBG2 a une protection N+1 avec deux groupes électrogènes 380 volts. L’un de ces 2 groupes BT était en « mode maintenance », donc cette sécurité n'a pas pu être utilisée.

Je suis aussi étonné que l'altération d’un des 2 câbles souterrains 20 000 volts d’Électricité de Strasbourg Réseau (ESR) ait été réparée si vite (a 10h39, ESR rétablit l’alimentation secteur, permettant la remise en service des 3 datacenter). Je n'ose pas imaginer si la panne avait durée plusieurs jours...

Sinon, oui, il faut féliciter OVH pour la transparence.


PS : J'ai séparé le HS dans un sujet à part Application des patchs de sécurité sous Linux

vivien

  • Administrateur
  • *
  • Messages: 27 071
    • Twitter LaFibre.info
Panne électrique majeure chez OVH (sites inacessibles)
« Réponse #119 le: Hier à 11:24:53 »
Le texte complet :

Bonjour,
Voici le post-mortem de l'incident.

Le jeudi 9 novembre, à 7 h 04, le site de Strasbourg, hébergeant 4 datacentres, a été privé d’énergie. Malgré toutes les sécurisations mises en place, la coupure électrique s’est propagée dans les datacentres et a provoqué un arrêt électrique de 40 386 serveurs hébergés sur le site.

À 10 h 39 le site a été réalimenté, puis les services ont progressivement redémarré. A 18 h 00, 71 % des serveurs étaient fonctionnels, et le vendredi 10 novembre à 23 heures, 99 % des serveurs étaient fonctionnels. Une minorité de services a été affecté jusqu’au dimanche 12 novembre.


Déroulé de l’incident en temps réel (jeudi 9 novembre) :
----------------------------------------------------------
7h04:07 : disjonction du côté d’Électricité de Strasbourg Réseau (ESR) et perte de l’alimentation électrique des deux lignes.
7h04:17 : les groupes électrogènes haute tension (HT) ne démarrent pas.
7h12:48 : l’onduleur 6 (UPS) arrive en fin d’autonomie batterie.
7h15:48 : l’onduleur 5 arrive en fin d’autonomie batterie.
7h17:25 : l’onduleur 2 arrive en fin d’autonomie batterie.
7h18:00 : les premières tentatives manuelles de redémarrage des groupes HT ont échoué.
7h18:39 : l’onduleur 1 arrive en fin d’autonomie batterie.
7h19:19 : l’onduleur 4 arrive en fin d’autonomie batterie.
7h21:00 : l’onduleur 3 arrive lui aussi en fin d’autonomie batterie.
7h21:00 : les salles de routage ne sont plus alimentées électriquement.
7h21:03 : nouvelle tentative manuelles de démarrage du groupe HT numéro 1.
7h22:42 : nouvelle tentative manuelles de démarrage du groupe HT numéro 2.
7h30 : la cellule de crise locale est opérationnelle.
7h50 : la cellule de crise centrale au siège de Roubaix est opérationnelle.
Entre 7h50 et 10h39 : multiples tentatives manuelles de redémarrage des groupes électrogènes accompagnées par nos experts en génie électrique.
10h39 : ESR rétablit l’alimentation secteur.
10h58 : les routeurs sont de nouveau joignables.
11h : les interventions sur les serveurs le nécessitant sont en cours.
14h : arrivée d’une première équipe renfort
16h : des renforts venus de nos sites de Francfort (Allemagne) et de Roubaix arrivent.
17h30 : un camion de 38 tonnes rempli de pièces détachées arrive sur place.
22h : 97 % des serveurs fonctionnent, 91 % répondent au ping.


Quelle est la cause de la disjonction côté ESR ?
------------------------------------------------
L’ensemble du site est alimenté par 1 alimentation électrique de 20MVA réalisée avec 2 câbles de 20kV. La cause de la disjonction est liée à une altération d’un des 2 câbles souterrains, qu’ESR a réparé rapidement. Les causes de l’altération de ce câble ne sont pas encore déterminées à date. Des investigations sont en cours par ESR.


Pourquoi la perte d’un câble a entraîné une coupure d’alimentation ?
--------------------------------------------------------------------
Le site de Strasbourg est alimenté par deux câbles délivrant 20MVA et donc connectés sur le même disjoncteur. Le déclenchement du disjoncteur a entraîné la coupure des deux lignes.


Pourquoi les générateurs haute tension ne se sont-ils pas mis en route ?
------------------------------------------------------------------------
SBG1 et SBG4 sont alimentés par 2 groupes électrogènes (HT), de 2MVA chacun, qui prennent le relais en cas de coupure électrique. L’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas démarré les groupes électrogènes.

Après investigation, nous avons constaté que l’ordre de démarrage des groupes haute tension (HT) n’avait pas été envoyé par l’automate pilotant l’inverseur.

Le fabriquant de cet automate est venu l’expertiser. Il s’avère qu’il était bloqué en défaut « automatisme verrouillé », ce qui explique l’absence de démarrage des groupes HT. Des investigations sont en cours pour comprendre l’origine de ce blocage.

L’équipe d’intervention du fabricant a remis l’automate en état de fonctionnement normal. Nous n’avons pour l’instant pas d’explication à cette erreur. En l’attente des conclusions, nous assurons la permanence en roulement d’une personne dédiée 24 heures/24 et 7 J/7 afin d’être en mesure de forcer la bascule manuellement pour parer à un éventuel nouveau défaut de l’automate.

Dans les prochains jours, nous allons réaliser le test en charge du site ce qui nous permettra de valider le bon fonctionnement de l’automate.


Pourquoi les tentatives de démarrage des groupes HT ont-elles échoué ?
----------------------------------------------------------------------
Le datacentre SBG2 est alimenté avec 2 groupes électrogènes BT de 1.4MVA chacun. L’un de ces 2 groupes BT était en « mode maintenance ». En « mode maintenance », dans le cas d’une coupure électrique, les 2 groupes électrogènes HT de SBG1 fournissent l’énergie à SBG2, à la place du groupe électrogènes BT en maintenance.

Jeudi le 9 novembre, lorsque que le site a été privé d’énergie, l’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas donné l’ordre de démarrage aux groupes HT.

Nous avons donc procédé à des tentatives de démarrage manuelles.

Pour faire fonctionner la charge électrique de SBG1, SBG4 et SBG2 avec l’un des deux groupes BT en « mode maintenance », il faut absolument que les 2 groupes HT fonctionnent ensemble afin de fournir 4MVA. Comme les 2 groupes électrogènes HT ne sont pas parvenus à se synchroniser, nous avons alors découplé les 2 groupes électrogènes HT pour les faire fonctionner séparèment. Un groupe seul délivrant uniquement 2MVA ne peut tenir la charge demandée et il s’arrête. Nous avons effectué de multiples essais dans différentes configurations, sans succès.


Combien de temps a-t-il fallu pour rétablir les services ?
----------------------------------------------------------
Des moyens exceptionnels ont été mis en place afin de rétablir au plus vite les services.


État des lieux général :
------------------------
Jeudi à 22 heures, 97 % des serveurs (hardware) étaient de nouveau fonctionnels ainsi que 91 % des services (software). Vendredi à minuit, 99 % des serveurs étaient de nouveau opérationnels ainsi que 96,2 % des services.

Dans le détail :

Private Cloud :
----------------
Jeudi 9 novembre
·       23h : 78,59% des vCenters opérationnels

Vendredi 10 novembre
·         5h : 100% des vCenters opérationnels


Object Storage/Cloud Archive :
-------------------------------
Jeudi 9 novembre, 13h35 : 100 % opérationnel


PCS :
-----
Jeudi 9 novembre, 13h35 : PCS/PCA 100% opérationnel

PCI/VPS* : (*zoning PCI : les « régions PCI » ont une nomenclature différente de celle des datacenters)
------------------------
11h30 : API est UP sur le région SBG1/SBG2/SBG3
17h : 98% instances OK région SBG3
20h00 : 98% instances OK région SBG1
21h00 : 92% instances OK région SBG2

Vendredi 10/11
16h00 : 100% instances OK région SBG1
16h30 : 100% instances OK région SBG2

Samedi 11/11
18h : 100% instances OK région SBG3


SD :
----
Jeudi 9/11
21h : 93,05% des serveurs dédiés sont opérationnels

Vendredi 10/11
17h : 99,1% des serveurs dédiés sont opérationnels


Comment avez-vous géré la situation ?
--------------------------------------
Dès 7 h 50, une cellule de crise est activée à Roubaix afin de coordonner toutes les actions des équipes. Octave Klaba, le CEO et fondateur d’OVH, rend compte de l’évolution de la situation en temps réel, via les réseaux sociaux. Des explications détaillées sont aussi fournies sur la tâche travaux.
 
En parallèle, les équipes support françaises s’organisent avec leurs homologues québécoises pour répondre à un maximum de sollicitations. Les clients Grands Comptes concernés sont contactés afin de leur apporter des solutions rapides et concrètes.
 
À Strasbourg, les équipes datacentres sont vite renforcées par des techniciens venus de nos centres de données allemands (Francfort) et français (Roubaix). Un véritable pont routier et ferroviaire est mis en place. Vers 17 h 30, un camion de 38 tonnes provenant du centre logistique d’OVH en métropole lilloise, leur apporte toutes les ressources matérielles additionnelles nécessaires pour les heures à venir. Plusieurs camions arriveront les jours suivants, suite à la mise en place d’une astreinte logistique à Roubaix.

Ces équipes ont ainsi travaillé sans relâche, nuit et jour, pour rétablir les services de tous les clients, allant jusqu’à justifier l’organisation et la mise en place d’un pont aérien entre Lille et Strasbourg afin d’accélérer les rotations des équipes présentes sur place durant le week-end et toute la semaine.


Quel est le plan d’action mis en place suite à cet évènement ?
---------------------------------------------------------------
Comme évoqué précédemment, nous avons immédiatement pris des mesures pour proscrire ce type d’incident à Strasbourg (SBG) ainsi que sur l’ensemble de nos sites.

Ce plan d’actions va se déployer en 2 phases.

À court terme
-------------
Nous avons demandé un rapport détaillé au fournisseur de l’automate.

Puisque le basculement de l’automate normal/secours motorisé n’a pas fonctionné, nous avons une présence dédiée 24 heures sur 24 et 7 jours sur 7, afin de pouvoir réaliser manuellement la manœuvre en cas de non-fonctionnement de l’automatisme. Cette astreinte sécurise le site en attendant qu’un test en charge puisse confirmer le bon fonctionnement de l’automate.

Pour la partie inverseur normal/secours, nous allons rapidement remplacer la partie automatisme par un automate « maison », qui nous permettra d’en maîtriser complètement le fonctionnement et de le monitorer. Un système identique est déjà en production à Gravelines.

Nous avons demandé un rapport détaillé à ESR concernant l’origine de l’avarie.

Une étude de faisabilité concernant le raccord d’une deuxième arrivée électrique de 20MVA est également lancée. En attendant, nous avons lancé une 2eme étude : la mise en place de 2 disjoncteurs isolés, un par câble, ce qui permettrait de secourir un éventuel défaut sur l’un des 2 câbles.

Nous allons effectuer la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4 ainsi que la séparation du futur SBG3, vis-à-vis de SBG2 et SBG1/SBG4. De cette manière, chaque datacentre disposera de son alimentation de secours indépendante.

Un audit électrique est également en cours pour l’ensemble de nos sites.

À noter : à l’heure actuelle, lorsqu’un serveur est commandé sur le site de Strasbourg, il apparaît par défaut au sein de l’espace client comme hébergé au sein de SBG1, même s’il est hébergé à SBG2 ou SBG4. C’est un bug d’affichage. Cette anomalie sera corrigée très rapidement afin de laisser apparaître le datacentre réel au sein duquel le serveur est hébergé.


À long terme
------------
La technologie basée sur les containers maritimes ne sera plus utilisée par OVH. En effet, elle n’a été utilisée que pour construire SBG1 et SBG4, et hérite des imperfections de design liées à la faible ambition initialement prévue pour le site. Aujourd’hui, nous réalisons qu’elle n’est plus adaptée aux exigences de notre métier et aux normes OVH. Nous allons donc démanteler SBG1 et SBG4.

Pour cela, une migration de l’ensemble des services de nos clients hébergés sur SBG1 et SBG4 sera opérée vers SBG2 et SBG3 ou sur d’autres datacentres OVH.


Nous sommes sincèrement désolés pour cette panne et nous faisons le nécessaire afin que ce type d'incident ne se reproduise plus.

Amicalement
Octave

 

Mobile View