Étiquette : Cloud

Pas de commentaire

J’ai testé Scaleway, la « Disruptive Cloud Platform »

  de

Dans l’optique de repenser ma plateforme Cloud personnelle et de changer de serveur car désormais surdimensionné par rapport à mes besoins, j’ai essayé Scaleway, qui est une filiale d’Online, qui propose des serveurs virtuels et physiques à des prix plutôt intéressants avec une interface simple et mettant en avant la flexibilité et la rapidité.

L’offre de Scaleway est plutôt simple à comprendre :

  • Les gamme Start, Pro et ARM sont basées sur des serveurs entièrement virtuels, cela signifie que les coeurs et RAM sont en partage avec d’autres utilisateurs sur le même serveur physique ;
  • La gamme BareMetal représente les serveurs physiques dédiés.
J’ai testé la gamme Start avec 2 types de serveurs :  le XS (1 core et 1 Go de RAM, pour 25 Go de disque) et M (4 cores, 4 Go de RAM et 100 Go de disque de base). 
Au niveau des CPU, il s’agit d’Intel Atom C3955 ; peu performants en soi par rapport à ce que l’on peut trouver dans des serveurs mais suffisants pour bien des usages et permettant d’offrir un prix plancher puisque le XS coûte 2,40€ par mois TTC maximum, la facturation étant à l’heure, un serveur qui est détruit dans le mois ne coûte que les heures où il a fonctionné. 
Concernant le stockage, c’est déjà un peu plus flou : il y a la notion de LSSD et de DSSD. Tous les disques chez Scaleway sont des SSD ; la différence entre le L et D SSD réside dans l’emplacement dudit stockage : le LSSD est en fait une allocation disque sur une baie de stockage en réseau, donc non-physiquement présente sur le serveur ou l’hyperviseur hébergeant votre machine, tandis que le DSSD est bel et bien un disque intégré au serveur. Ce qui est dommage, c’est que seul le plus gros serveur BareMetal comprend un DSSD ; pour le reste on est obligé de passer par la case disque réseau. Les performances sont cependant au rendez-vous, mais il faut garder à l’esprit qu’en fonction du noeud sur lequel notre serveur est installé cela peut fluctuer :
Seul le plus petit modèle héberge un LSSD de 25 Go, les autres serveurs offrent au minimum 50 Go de disque, extensibles par tranche de 50 Go, soit sur le même disque, soit en disque supplémentaires si l’on souhaite plusieurs points de montage. Dommage que la partition système ne soit pas extensible et soit figée à 50 Go. Par ailleurs, cela n’est pas précisé mais certains types de serveurs ont une limite de disques rattachables en nombre mais pas en taille ; si 1 To est le maximum de stockage pouvant être accolé à un serveur, au final sur un S on ne peut attacher qu’un disque, sur un M il n’est pas possible de rattacher un troisième disque, et ce qui est quelque peu idiot est qu’une fois un disque rattaché il n’est pas possible d’en augmenter sa taille (quelle raison, étant donné que ce ne sont que des allocations sur une baie ?)…
Le concept de flexibilité chez Scaleway est plutôt important car au final, le serveur n’est qu’un objet au même titre que les IP ou le stockage ou les images de déploiement ; on peut monter ou démonter nos LSSD sur n’importe quel serveur, supprimer un serveur sans perdre le stockage associé, etc. L’interface de gestion est plutôt claire et agréable à utiliser, même si potentiellement déroutante au départ pour qui ne parle pas anglais et/ou est néophyte. Quelque part le prix plancher des offres se paye par le support limité malgré une documentation relativement fournie par rapport aux services offerts.
La gestion d’un serveur est plutôt minimaliste mais a le bon goût d’offrir un accès console, permettant quand même de maniper au cas où le SSH est par terre ou bien que nous sommes connectés depuis une IP habituellement rejetée par SSH. On retrouve le nom du serveur, son emplacement géographique (Paris ou Amsterdam), son IP publique, son IP sur le réseau interne (qui change à chaque fois que vous éteignez ou rallumez votre serveur), et d’autres informations, y compris les disques. Par défaut, la connexion à un serveur se fait avec votre clé SSH renseignée dans votre compte.
La création d’un serveur est plutôt rapide, il doit se passer à tout casser 2 minutes entre le moment où l’on arrive sur la page de création et le moment où celui-ci est effectivement disponible :
On choisit la taille du serveur désiré, la distribution ou application pré-installée (par exemple WordPress, PrestaShop, OpenVPN…) ou encore un déploiement par rapport à une image que vous avez créé vous-même (et non pas un ISO personnalisé…) et c’est parti. Le choix de distributions comprend l’essentiel et se limite au monde GNU/Linux ; la virtualisation se base sur KVM et il n’y a pas de Windows disponibles.
Au niveau réseau, pas de grosse surprise, sur 300 Mbps annoncés :
Lorsqu’on souhaite éteindre un serveur, le stockage est déplacé de la baie de stockage vers des « archives » et le serveur n’est plus accessible immédiatement. Ensuite, lorsqu’on souhaite le rallumer, le stockage redescend vers la baie et les coeurs sont de nouveau alloués ; cependant il arrive que le processus de « rallumage » de serveur prenne du temps car les ressources ne sont pas disponibles ; il convient donc de laisser allumé le serveur 24/7 à moins de vraiment vouloir tirer jusqu’au bout la notion de facturation à l’heure… et pour rendre le serveur indisponible on pourra plutôt couper la patte réseau afin qu’il ne communique plus via la console intégrée.
Actuellement, il ne me reste chez Scaleway que le miroir du blog (basé sur un lighttpd tout simple) ; j’y avais 3 autres serveurs que j’ai fini par bouger ailleurs sur un hyperviseur basé sur Proxmox. En effet, la puissance un peu légère des processeurs pour faire fonctionner Plex et quelques autres applications était problématique, et la gestion du stockage méritait d’être améliorée car en total décalage avec la flexibilité annoncée et plutôt réelle du reste des éléments du cloud. En l’état, Scaleway est une très bonne plateforme pour y monter des serveurs peu critiques ou pour se monter des labos de tests ou encore une petite infrastructure cloud légère ; en gros pour des besoins particuliers. Pour un usage professionnel ou plus sérieux, d’autres fournisseurs me semblent plus adaptés.
Si je devais faire un bilan de mon expérience chez Scaleway en deux semaines :
  • Points forts : tarifs intéressants et à l’heure, rapidité de build d’un serveur, large panel de configurations matérielles, performances disques et réseau suffisantes dans une majorité de situations, flexibilité
  • Points faibles : gestion du stockage, support limité en version de base, interface uniquement en anglais, disponibilité de l’infrastructure lors de la remise en route d’un serveur incertaine.
Pas de commentaire

Présentation de mon « cloud » personnel

  de

Je possède une plateforme en ligne me permettant entre autres d’assouvir ma curiosité IT mais également de répondre à plusieurs besoins – que je me suis moi-même créé, d’ailleurs. Après avoir eu pendant longtemps un serveur (généralement sous Debian), il y a quelques temps j’ai décidé de passer sur une plateforme virtualisée afin de séparer chaque fonctionnalité de mon nuage et de gérer les choses plus facilement. Initialement sous Proxmox VE, je suis passé sous VMware après l’avoir pratiqué dans un contexte professionnel. Le but de cet article est d’essayer de présenter ce nuage, ce que j’en fais, comment je l’ai pensé et comment il vit.

Tout d’abord, ce nuage est basé sur une seule machine physique. Il s’agit d’un serveur que je loue chez SoYouStart qui est le milieu de gamme de chez OVH (l’entrée de gamme étant assurée par Kimsufi et le haut de gamme par OVH lui-même). Sa configuration est la suivante :

  • CPU : AMD Opteron 4334 à 6 coeurs, 6 threads et 3.1 GHz
  • RAM : 32 Go DDR3 1333 MHz
  • HDD : 2 x 3 To SATA, configurés en RAID 1
Il s’agit de la configuration OP-SAT-1-32. Après plusieurs années sur un modèle moins puissant fonctionnant sous Proxmox VE, j’ai fait ce choix car les 32 Go de RAM sont le minimum dont j’ai besoin dans le cadre de la virtualisation afin de ne pas dimensionner un peu court les machines ; le processeur plutôt puissant suffit à toutes les tâches et ne peine pas face à de multiples décodages de vidéos en 1080p sur Plex ; les disques durs, bien que simples SATA en 7200rpm suffisent même si le confort des SSD que j’ai pu essayer manque à l’appel, en ayant en contrepartie un espace suffisant pour tout type de machine virtuelle.
La couche de virtualisation est un VMware ESXi 6.5u1. Elle héberge donc – entre autres, je ne vais présenter que les machines qui sont permanentes – :
  • 1 appliance pfSense, fonctionnant sous BSD ;
  • 2 contrôleurs de domaine sous Windows Server 2012 R2 ;
  • 1 serveur de fichiers sous Windows Server 2012 R2 ;
  • 1 serveur applicatif sous Windows Server 2012 R2 ;
  • 1 serveur RDP sous Windows Server 2012 ;
  • 2 serveurs multimédia Plex sous Debian ;
  • 1 serveur applicatif sous Debian ;
  • 1 serveur VPN sous Debian ;

L’appliance pfSense : 1 vCPU et 512 Mo de RAM

J’en ai déjà parlé dans ce billet. pfSense est un serveur BSD pouvant entre autres remplir le rôle de routeur/pare-feu. Etant donné qu’à la différence de Proxmox VE qui permet de faire du NAT nativement grâce à iptables, l’adoption de VMware m’a forcé à passer par une solution tierce pour mettre en réseau mes machines virtuelles derrière un pare-feu en n’utilisant qu’une seule IP publique. Mon serveur fonctionne donc avec deux adresses IP : l’une utilisée par la carte physique, l’autre en IP failover utilisée par l’interface virtuelle de pfSense et qui sert d’IP publique pour mes machines virtuelles et de base pour le routage des paquets vers les bons ports.

Les contrôleurs de domaine : 1 vCPU, 2 Go de RAM et 120 Go d’espace disque par DC

Je pourrais très bien fonctionner avec un seul contrôleur de domaine étant donné que je ne possède qu’un seul serveur pour héberger toutes mes machines et qu’il n’y a aucune notion de haute disponibilité. Cependant, ayant déjà eu le cas d’un contrôleur de domaine complètement planté suite à une mise à jour qui s’est mal déroulé sur une précédente infrastructure personnelle, je préfère en avoir deux fonctionnant de concert ce qui me permet de toujours avoir le domaine même si une mise à jour ou un plantage grave arrive sur l’un (corruption du fichier VMDK par exemple, ce qui m’est déjà arrivé).
Le premier porte tous les rôles (FSMO, PDC…), les deux ont le rôle DNS et ont été installés avec l’interface graphique. C’est un point que je souhaite changer prochainement et qui fera sans doute l’objet d’un billet. Ayant toutes les consoles d’administration sur une autre machine, je ne m’y connecte que très rarement et fonctionner uniquement en mode core pourrait limiter la consommation – déjà très faible – de ressources.

Le serveur de fichiers : 2 vCPU, 3 Go de RAM et 3 disques virtuels pour un total de 720 Go

Ce serveur fonctionnant sous 2012 R2 me sert pour stocker une partie de mon OneDrive, ainsi qu’héberger divers espaces partagés entre les machines (sources d’applications, scripts, téléchargements, bases de données…). J’y stocke également les sauvegardes des serveurs Windows que je réalise grâce à l’outil intégré. Afin d’avoir une compatibilité maximale avec les applications, ce serveur fait fonctionner un serveur FTP fonctionnant sous FileZilla.

Le serveur applicatif sous Windows : 2 vCPU, 3 Go de RAM et 2 disques virtuels de 120 Go

J’utilise cette VM pour faire fonctionner des applications qui ont besoin d’un environnement Windows (ou qui sont plus faciles à faire fonctionner ou configurer sous Windows). Je m’en sers principalement pour faire fonctionner un serveur Minecraft personnel ou d’autres serveurs de jeux, afin de ne pas avoir à conserver les fichiers et exécuter le serveur dédié sur mon propre PC personnel. Cela me permet également de donner accès à des personnes de ma famille qui sont en dehors de mon réseau personnel. 

Le serveur RDP : 2 vCPU, 2 Go de RAM et 120 Go d’espace disque

C’est ce serveur qui permet de rebondir sur le reste du réseau et le seul RDP à être ouvert sur l’extérieur. Plutôt que d’ouvrir les RDP ou les bureaux graphiques des autres machines, j’ai préféré tout fermer et ne laisser l’accès que depuis cette seule machine afin de limiter le nombre de ports à nater. Cette VM possède ensuite tous les clients nécessaires à la connexion aux services VMware de l’hyperviseur, aux bureaux graphiques des machines Linux, PuTTY pour le SSH, sans oublier les consoles d’administration pour les services répartis sur les serveurs. Plus qu’un serveur de rebond, il s’agit également d’un serveur d’administration et c’est sur cette machine que je réalise la majorité de mes scripts. Pour des questions de sécurité, la connexion à cette machine se fait avec un autre compte utilisateur que les autres machines Windows, ce compte n’ayant aucun autre droit sur le domaine (et mon compte utilisateur standard n’ayant aucun droit sur le serveur RDP, seul mon compte d’administration ayant des droits transverses).

Les 2 serveurs Plex : 4 vCPU, 4 Go de RAM et 50 Go d’espace disque pour le premier, 1 vCPU, 2 Go de RAM et 100 Go d’espace disque pour le second

Pourquoi deux serveurs Plex ? Car ils fonctionnent différemment.
Le premier serveur Plex, avec sa grosse configuration, est dédié à la diffusion de contenu vidéo. Films, séries, concerts, émissions TV… tout ce qui peut demander une bonne puissance de calcul en cas de diffusion sur un appareil qui ne peut décoder le flux directement (comme un iPad). Comme je l’ai expliqué dans ce billet, le contenu n’est pas stocké directement sur le serveur, mais en ligne, sur Google Drive. J’utilisais auparavant Amazon Drive mais le blocage complet de l’API suivi d’un changement des grilles tarifaires m’a fait résilier mon abonnement pour me diriger vers celui de Google, qui s’est avéré plus fiable, plus rapide pour pas beaucoup plus cher dans l’absolu (8 euros par mois contre 70 euros à l’année). Afin de supporter le streaming sur plusieurs appareils (généralement un seul, mais 3 devant être un nombre géré sans problème avec du 1080p), il a fallu dimensionner correctement la machine et 4 cœurs virtuels sont suffisants.
Le deuxième serveur Plex à la configuration bien plus modeste est dédié à la diffusion de contenu audio. La musique est stockée directement sur le disque de la machine virtuelle afin de ne pas avoir à faire des appels à l’API de Google Drive sans arrêt à chaque changement de piste, sans compter que 100 Go sont aisément disponibles sur l’hyperviseur.

Le serveur applicatif Debian : 2 vCPU et 2 Go de RAM pour 120 Go d’espace disque

Cette VM héberge un serveur web, un serveur de base de données MySQL, ainsi que quelques autres applicatifs web. L’usage est principalement local, certaines applications dont je me sers peuvent avoir besoin d’une base de données, par exemple. Grâce à des scripts conçus sous Webmin, les bases de données ainsi que certains fichiers sont sauvegardés sur le serveur de fichiers, qui lui-même les sauvegarde par la suite sur OneDrive, ce qui me permet de pouvoir restaurer à un instant T si besoin.

Le serveur VPN : 1 vCPU et 1 Go de RAM pour 10 Go d’espace disque

Afin de pouvoir profiter de réseaux Wi-Fi publics sans me sentir « nu », ce petit serveur VPN est idéal. Fonctionnant sur une base d’OpenVPN Access Server, l’installation et la configuration se font très facilement, et des clients existent aussi bien pour les ordinateurs que les appareils mobiles. Je m’en sers dès que je suis sur un réseau Wi-Fi qui n’est pas celui que j’utilise à la maison. 
Et c’est déjà pas mal ! J’ai également possédé pendant quelques temps un serveur de messagerie personnel, lié à mon nom de domaine, dont je me servais à des fins personnelles, connecté à mes clients de messagerie ou accessible via un webmail. Fonctionnant sous Debian avec Postfix et Dovecot, lorsque j’ai repensé intégralement l’architecture en adoptant VMware, j’ai décidé de ne pas conserver la messagerie personnelle. Trop peu d’utilité et de confort par rapport à mon usage : sauvegarde horaire de la boîte aux lettres, adresse considérée chez certains destinataires comme spam, difficulté de configuration… Concernant le dimensionnement des machines, il est plutôt large, et d’ailleurs, si toutes les machines devaient occuper 100% de leurs vCPU, cela saturerait l’hyperviseur ; cependant, très peu de risque que cela arrive. En moyenne, le CPU tourne entre 5 et 10% de ses capacités, avec une moyenne à 30% lors de la diffusion de médias via Plex. Actuellement, le serveur en est à 245,24 jours de fonctionnement… et ça n’est pas prêt de s’arrêter.
Pas de commentaire

Mise en place de google-drive-ocamlfuse

  de

Je passe pas mal de temps à regarder les meilleures options pour coupler Google Drive à Plex, et je me suis heurté récemment à un problème par rapport à l’API de Google Drive en utilisant rClone. Lorsque Plex analyse les bibliothèques pour la première fois, il passe par rClone qui émet une requête à l’API. Cependant, lorsqu’on a énormément de médias (dans mon cas, 4,6 To), les requêtes se multiplient et le compte utilisé dépasse le quota ; quota remis à zéro toutes les 24 heures. Cela peut s’avérer problématique car Plex ne peut du coup indexer tout correctement en une fois. Ce souci est dû au fait que rClone ne garde pas en cache l’arborescence des fichiers, ce qui fait qu’il doit interroger Google en permanence, au lieu de simplement la télécharger une fois et s’y référer lors des accès, en faisant évidemment des mises à jour périodiquement ; comme si un livre n’avait pas de table des matières pour lister les chapitres. Bien que ce soit une évolution prévue dans la prochaine version de rClone (1.37), en attendant, j’ai préféré opter pour une autre solution afin de satisfaire également ma curiosité.

Au lieu d’utiliser donc rClone pour coupler mon Plex à Google Drive, je vais utiliser google-drive-ocamlfuse, que je vais abréger par la suite en GDO, qui remplit le même rôle mais qui ne fonctionne qu’avec Google Drive, là où rClone est nettement plus polyvalent.

Je pars du principe que vous êtes avec un compte utilisateur root ou en utilisateur standard ayant une élévation grâce à sudo en ce qui concerne les premières commandes. Mon serveur Plex fonctionne sur Debian Jessie mais l’installation est presque Plug’n’Play sur Ubuntu (ajout d’un repository au préalable, voir sur cette page).

1. Installation

Si l’application est disponible pour certaines distributions (Ubuntu, ArchLinux…), elle n’est pas disponible directement pour Debian. Il y a donc des manipulations à réaliser en plus. Ces manipulations ont été traduites directement depuis la page Wiki officielle du projet, je les ai quelque peu clarifiées en même temps.

Dans un premier temps, il faut installer entre autres les paquets CAML, fuse, puis également make puisqu’on va devoir compiler depuis la source de l’application.

apt-get install opam ocaml make fuse camlp4-extra build-essential pkg-config

Ensuite, si le groupe fuse n’existe pas déjà sur le système, il faut le créer et ajouter le compte qui lancera l’application. Pour ma part, je me sers d’un compte générique tout simple et non de mon compte utilisateur.

groupadd <username> fuse

Ensuite, sur le répertoire de fuse, on va appliquer les bonnes autorisations afin que l’utilisateur qui va lancer google-drive-ocamlfuse puisse utiliser fuse :

chown <username> /dev/fuse
chmod 660 /dev/fuse

Attention : on ne manquera pas d’exécuter les instructions suivantes avec l’utilisateur qui exécutera GDO.

Puis, on installe ce qui est nécessaire au téléchargement et à la complication de google-drive-ocamlfuse (opam est un gestionnaire de paquets ocaml). Tout comme ce qui est indiqué dans la manipulation, j’ai laissé les options par défaut et cela fonctionne très bien.

opam init (option par défaut : N)
opam update
opam install depext
eval `opam config env`
opam depext google-drive-ocamlfuse (si des paquets système manquent, ils seront installés)
opam install google-drive-ocamlfuse (valider l’installation des paquets ocaml, le make du paquet ocamlnet est plutôt long, c’est normal)

Et voilà, GDO est installé et prêt à être lancé !

2. Premier lancement et autorisation



Si la machine sur laquelle est installé GDO possède un navigateur web, alors le premier lancement et l’authentification auprès du compte Google est aisée.

Sinon – ce qui a été mon cas –, il faut obtenir des identifiants développeurs auprès de Google (il existe le même type d’identifiant sur Amazon, par exemple) et les renseigner dans l’application via le terminal.

En se rendant sur cette page, on s’identifie à son compte Google, puis on crée un projet auquel on donne un nom sans intérêt, puis on active l’API Drive, comme sur la capture d’écran :

Sur le site pour les développeurs de Google, il suffit d’aller sur le tableau de bord et d’activer l’API Google Drive

Puis, on va procéder à la création des identifiants dont on a besoin. Naturellement, quelques paramètres sont à choisir, mais rien de très complexe, au final on ne donnera qu’un nom qui apparaîtra sur la page d’authentification un peu plus tard :

On choisira ici « ID client OAuth » car notre application a besoin de pouvoir accéder au contenu du Drive

A la fin de la création, deux identifiants sont communiqués : un ID Client et un Secret Client. Il convient de les noter par exemple dans un notepad car on va en avoir besoin juste après.

De retour sur le terminal, on exécute l’application, avec quelques paramètres :

google-drive-ocamlfuse -headless -id <client ID>.apps.googleusercontent.com -secret <secret ID>

Une URL apparaît alors dans le terminal. On copie-colle cette URL dans un navigateur web (donc, sur une autre machine), et il suffit de se connecter à son compte Google et à valider… notre propre application à s’authentifier. Une fois que l’autorisation est donnée, un token apparaît – qui n’est valide que 15 minutes, il me semble. C’est ce token qu’attend GDO pour finir d’être initialisé. Une fois cette manipulation terminée, l’application à accès au Drive.

Il reste un point à noter : en cas de redémarrage du système, on ne pourra plus relancer l’application ; elle apparaîtra comme introuvable. Il faudra relancer l’instruction suivante pour « réanimer » OPAM :

eval `opam config env`

Si l’on est amené à redémarrer fréquemment le serveur, il est tout à fait possible de placer cette instruction dans un script qui sera exécuté au démarrage par exemple.

3. Configuration

Avant tout lancement, il convient de passer en revue le fichier de configuration afin de modifier ce qui doit l’être pour un bon fonctionnement, et dans mon cas, éviter de générer trop de requêtes à l’API afin d’éviter d’être de nouveau bloqué.

Le fichier de configuration se trouve dans le répertoire de l’utilisateur qui a installé l’application – d’où l’intérêt de ne pas le faire en root, mais avec le compte qui exploitera le Drive. Un éditeur de texte comme nano fera le job pour y accéder :

cd #
nano  .gdfuse/default/config

Je ne vais pas passer en revue toutes les options, cependant je vais parler de celles qui me paraissent les plus importantes ou intéressantes :

  • metadata_cache_time : intervalle de temps entre deux requêtes à Google pour voir si le contenu a changé.
  • read_only : comme son nom l’indique, cela permet de monter le Drive en lecteur seule. J’ai choisi cette option à true car je ne fais que de la lecture sur les fichiers.
  • download_docs : cette option permet de choisir si l’on veut télécharger ce qui est stocké sur Google Documents. Je l’ai passé à false dans une optique de limiter le trafic et les appels à l’API.
  • delete_forever_in_trash_folder : ce paramètre peut être dangereux si réglé sur true, car si les fichiers sont supprimés de la corbeille sur la machine, ils sont définitivement supprimés ; en étant sur false, l’application ne les supprime pas du Drive mais ne les affiche plus, il faut donc se connecter sur l’interface web pour les restaurer.
  • shared_with_me : affiche ou non dans un répertoire /shared les fichiers partagés depuis d’autres Drive.
  • max_download_speed, max_upload_speed : sans équivoque, permet de contrôler la bande passante.
  • max_cache_size : en Mo, il s’agit du cache local concernant les fichiers accédés. Plex permettant de diffuser des films, j’ai augmenté le cache par défaut de 512 Mo à 5 Go.

Quelques options dans le cadre d’une utilisation avec Plex sont intéressantes :

stream_large_files : par défaut sur false, cette option permet de choisir si le serveur garde en cache le fichier qui dépasse la limite choisie dans le paramètre large_file_threshold_mb. Je l’ai laissée à false afin de récupérer le fichier une fois pour toutes et minimiser le trafic depuis et vers le Drive en permanence.

A noter que si cette option est sur true, il est possible de régler le nombre et la taille des tampons grâce à memory_buffer_size et read_ahead_buffers (par défaut, 3 tampons de 1 Mo). On peut également limiter la consommation en RAM de ceux-ci avec max_memory_cache_size. A noter que les valeurs à exprimer sont en octets (réels, c’est-à-dire 1048576 pour 1 Mo).

Si besoin, il est possible de trouver toute la documentation avec toutes les options possibles sur cette page. Globalement, les paramètres par défaut sont plutôt satisfaisants et nécessitent que peu de réglages manuels.

4. Montage

Maintenant que tout est prêt, on va pouvoir passer au montage du Drive et à l’accès aux fichiers.

google-drive-ocamlfuse /home/test/media/

Si tout s’est bien passé, le montage est instantané et il n’y a aucun retour, il suffit de naviguer dans le répertoire monté pour accéder aux fichiers. Afin de démonter le Drive, il suffit d’appeler fuse avec cette commande :

fusermount -u /home/test/media/

Et voilà, on a couplé – avec tout de même un peu plus de difficulté qu’avec rClone – Google Drive et un système GNU/Linux.

Page Github de google-drive-ocamlfuse
Page d’accueil des API Google

Pas de commentaire

J’ai testé Plex Cloud, ou l’accès à ses médias depuis n’importe quel appareil

  de

Cela fait environ 3 ans que j’utilise Plex au quotidien. Plex est un serveur de médias comme Kodi (ex-XBMC). Il analyse les médias audio, vidéo et même image en les triant et en permettant une diffusion via internet ou le réseau local sur n’importe quel appareil équipé d’un navigateur web ou de l’application adéquate.

Si au départ, j’avais installé Plex sur une machine virtuelle avec 1 To de stockage, je suis arrivé au bout d’un moment plutôt à court d’espace. Je suis passé l’année dernière sur une solution de stockage sur OneDrive : étant abonné à Office 365, je possède 1 To en ligne sur les serveurs de Microsoft pour y stocker ce que je souhaite. Je me servais donc de l’espace pour y loger mes films et séries en sauvegarde, rapatriant ce que je regardais en temps voulu sur le serveur. Puis est arrivé Amazon Cloud Drive avec son stockage illimité à 70 euros à l’année. A l’aide d’outils comme acd_cli puis rClone (voir les deux billets précédents, ici et là), mon serveur Plex installé sur un système GNU/Linux lisait les médias stockés directement en ligne et non plus en local sur la même machine, ce qui m’enlevait l’épine du pied qui est le stockage local. Cependant, ces outils ont fini par être interdits par Amazon pour des raisons diverses, et j’ai donc dû trouver un workaround afin de pouvoir continuer de profiter de mon contenu multimédia en ligne sans avoir à stocker ces éléments sur la machine virtuelle.

Depuis quelques temps, Plex propose pour les abonnés à Plex Pass (un sorte de compte premium offrant des fonctionnalités supplémentaires) la fonction Plex Cloud. Dans un fonctionnement normal, Plex est installé sur une machine que vous possédez : l’encodage de la vidéo si nécessaire pour l’appareil de lecture et l’analyse de la bibliothèque est réalisé à partir des ressources de cette machine ; ressources demandées qui peuvent être élevées en cas de multiples lectures (3 lectures à décoder en 1080p, par exemple). Et là, le petit PC que l’on a recyclé en Plex ou le Raspberry Pi peuvent être un peu courts en termes de puissance CPU nécessaire. L’intérêt de Plex Cloud est de s’affranchir de cette nécessité d’avoir une machine de traitement chez soi ou loué chez un prestataire comme OVH par exemple, car ce sont les serveurs de Plex qui s’occupent du décodage et du traitement de la bibliothèque, ainsi que de l’acheminement réseau. J’ai donc basculé sur Plex Cloud il y a quelques jours, en connexion avec Google Drive.

Les points forts de Plex Cloud :

  • Le fait de ne plus avoir à se préoccuper des ressources CPU ou réseau du serveur Plex. Dans mon cas, mon serveur Plex était installé sur une machine virtuelle équipé de 4 vCPU (AMD Opteron 4334) et 4 Go de mémoire vive – ce qui permettait de tenir sans faiblir une utilisation de 2 ou 3 films décodés en 1080p pour des tablettes ou des appareils mobiles transmettant sur une Chromecast, par exemple.
  • L’intégration avec OneDrive, GoogleDrive ou Dropbox, en natif. Il n’est plus nécessaire d’utiliser des outils pour monter ces accès sur le disque, que ça soit sous Windows ou GNU/Linux. Il suffit de se connecter avec son compte sur l’interface de Plex Cloud afin que l’association se fasse, et ensuite, l’ajout des répertoires pour les diverses bibliothèques est naturel.
  • La fiabilité du système. Cela fait quelques jours que je me sers de Plex Cloud (un peu plus d’une semaine), et je n’ai rencontré aucun dysfonctionnement. La mise à jour des bibliothèques est plutôt rapide, la lecture des médias ne pose pas de problèmes, les temps d’accès plutôt faibles, et le débit correct, sans saccade ni coupure pour mettre en tampon, même en 1080p. Il est évident que cela n’est pas aussi rapide qu’avec un accès local, mais malgré tout les avance et retour rapides ne posent pas de soucis majeurs.
  • La possibilité de partager les bibliothèques Plex Cloud comme les bibliothèques d’un serveur standard. Encore une fois, cette possibilité permet une transparence d’utilisation et de fonctionnement identique à celle d’un serveur Plex standard installé sur une machine propre.
Les points faibles de Plex Cloud :
  • Plex Cloud nécessite un Plex Pass. Il s’agit d’un compte premium, que l’on peut prendre soit au mois, à l’année, ou à vie. Bien qu’il apporte des fonctionnalités plutôt intéressantes dans le cadre d’une utilisation nomade, en utilisation simple il n’a pas nécessairement d’intérêt. La fonctionnalité n’est pas gratuite, même si cela est compréhensible, la solution revient plus chère sur le papier que l’installation d’un serveur Plex sur une machine à la maison.
  • 3 connexion maximales possibles. Plex Cloud est limité à trois diffusions de médias ; même si cela est suffisant dans l’absolu, il n’est pas possible de faire lire toute la famille par exemple un média différent sur Plex Cloud, alors que cela est possible par exemple sur un serveur Plex standard (si bien sûr, les ressources CPU et réseau sont suffisantes).
  • Dépendance à la plateforme Plex et aux fournisseurs associés. Plutôt évident : si les serveurs de Plex rencontrent des difficultés, ou le fournisseur de Cloud auquel vous êtes rattaché, la diffusion peut être problématique.
  • 3 fournisseurs supportés pour l’instant : Google Drive, Dropbox et OneDrive. Même si ils sont les plus connus du marché, il est dommage que d’autres acteurs comme Amazon Drive (qui était présent en bêta mais qui a été retiré) ou Hubic ne soient pas disponibles.
  • Certains formats de sous-titres non reconnus. Certaines vidéos peuvent ne pas être lues si des sous-titres externes (format .srt) sont sélectionnés. Je n’ai pas rencontré ce cas de manière systématique, mais cela est arrivé, alors que la diffusion ne pose pas de problème avec un serveur Plex classique.
Pour ma part, j’ai choisi Google Drive comme espace de stockage. Si j’utilise actuellement Plex Cloud pour mes médias, j’attends que le transfert depuis Amazon Drive sur lequel était stocké mon contenu soit terminé afin de monter sur ma machine virtuelle Plex un accès à Google Drive avec rClone afin de pouvoir bénéficier, si défaillance de mon serveur ou de Plex Cloud, d’une infrastructure secondaire. De plus, cela me permettra d’avoir l’assurance de ne jamais être à court de ressources qu’elles soient réseau ou processeur pour profiter de mon contenu.