
Filtre actif, cliquez pour en enlever un tag :
Cliquez sur un tag pour affiner votre recherche :
Résultat de la recherche (10 notes) :
Pourquoi le badge Website Carbon me dérange ?
Je viens de voir à nouveau un badge Website Carbon Calculator sur un site.
Ce type d'initiative me dérange, parce que je considère la méthode de calcul comme non rigoureuse.
Quelques exemples :
- Elle semble ne pas prendre en compte la consommation du device côté client (smartphone, desktop…) ;
- Elle semble ne pas prendre en compte la charge cotée serveur.
Je pense que les personnes qui intègrent ce type de badge sur leur site sont dans une démarche de Greenwashing. Je pense qu'elles ne maitrisent pas le sujet.
Le projet Lighthouse est bien plus honnête dans sa démarche. N'étant pas en mesure de donner des mesures rigoureuses, il semble avoir abandonné ce projet : 🍃 adding environment protection KPI and audits (like CO2 footprint)
Pour fournir une information plus rigoureuse, je pense qu'il serait possible d'agréger les statistiques de consommation via PowerTOP de tous les serveurs qui servent à héberger le site web, croiser cette information avec les statistiques de visites tout en prenant en compte les caractéristiques énergétiques du data center.
Mais, tout cela est très compliqué.
En attendant, je pense qu'il est bien plus honnête de simplement intégrer un badge Lighthouse qui prends en compte les paramètres suivants :
- la taille de la page et de ses dépendances ;
- la complexité de rendu de la page.
Plus la note Lighthouse est élevée, moins le site web consomme d'énergie, à conditions égales.
Exemple : https://sklein.xyz/reports/report.html
Voir aussi : co2.js.
Journal du jeudi 31 octobre 2024 à 12:53
Je viens de faire ma première "contribution" à la coopérative social.coop 😉 : mon message posté dans le thread "TWG is exploring server hosting alternatives".
Journal du jeudi 31 octobre 2024 à 12:34
Note de comparaison de la localisation des serveurs Hetzner et Scaleway.
Pour Hetzner je lis ceci :
Pour Scaleway, je lis ici :
All Dedibox servers and associated services are hosted in our Paris & Amsterdam datacenters. We also have a Warsaw datacenter.
Journal du lundi 09 septembre 2024 à 15:00
Dans cette note, j'essaie autant que possible de comparer des offres Bare-metal server, Elastic Metal et Virtual Instances de Scaleway, pour une puissance égale.
Je lis ici que les Virtual Instances "Workload-Optimized - POP2HC
" sont exécutés sur des serveurs « AMD EPYC™ 7003
Series processors ».
Le serveur Dedibox Core-9-L
avec un CPU "AMD EPYC 7313P
" fait partie de la famille des 7003, équivalent je pense aux serveurs qui font tourner les Virtual Instances POP3HC
.
Coté Elastic Metal, j'ai identifié le modèle EM-I210E-NVME
avec un processeur de la famille 7003 : "AMD EPYC 7313P
".
Tarif de ce serveur avec un engagement au mois : 239,99 € / mois et sans cet engagement : environ 480 € / mois.
Si je fais un bilan de comparaison :
- Dedibox
Core-9-L
: 249 € / mois avec 256 GB de Ram et 3x1TB, engagement au mois. À cela il faut ajouter 329.99 € de frais de setup. - Elastic Metal
EM-I210E-NVME
: 239 € / mois avec 128 GB de Ram et 2x1.9 TB, engagement au mois. À cela il faut ajouter 239,99 € de frais de setup. - Elastic Metal
EM-I210E-NVME
: 480 € / mois avec 128 GB de Ram et 2x1.9 TB, engagement à l'heure - Virtual Instances
POP2HC
: 1464 € / mois, avec 256 GB de Ram et 3TB de volume
À puissance égale, une Virtual Instances est approximativement 6 fois plus cher qu'une Dedibox (sans prise en compte des frais de setup Dedibox qui s'élèvent à 329 €).
Il est important de noter que je pourrais manquer d'informations concernant les serveurs hébergeant les Virtual Instances, ce qui pourrait entraîner des erreurs dans mon analyse.
Je tiens également à préciser qu'une Virtual Instance offre, en théorie, une meilleure fiabilité grâce à la possibilité — toujours en théorie — de migrer à chaud d'un serveur à un autre.
Journal du jeudi 23 mai 2024 à 21:39
#OnMaPartagé https://www.ubicloud.com
Ubicloud offers infrastructure-as-a-service (IaaS) features on providers that lease bare metal instances, such as Hetzner, OVH, and AWS Bare Metal. It’s also available as a managed service.
Journal du jeudi 25 avril 2024 à 20:44
Le 25 octobre 2020, j'ai commandé et installé un serveur Dedibox (Start-2-S-SSD
- Intel® C2350 (Avoton)
- 4 GB DDR3
- 1x 120 GB SSD
) que j'ai nommé perier
Position du serveur : Datacenter: AMS1, Room: Hall 6 12, Rack: 6.12.53, Block: C, Position: 8
.
Prix de cette machine : 5,48 € TCC par mois, 66 € / an.
Coût total entre octobre 2020 et avril 2024 : 42 mois x 5,48 € = 230 €.
Aucune panne, pendant 42 mois.
J'utilisais cette machine principalement pour du stockage web statique.
J'y hébergeais https://sklein.xyz.
Ce jeudi 25 avril 2024, cette machine est tombée en panne, réponse du support :
Navré de la situation, il s'agit d'une erreur matérielle qui ne permet pas la récupération de données. Pourriez-vous vérifier l'état de vos sauvegardes.
Chose surprenante, le même modèle de serveur de mon ami AM a, lui aussi, une panne matérielle, exactement au même moment que moi.
Autre chose surprenante, la panne est tombée le même jour que cet incident déclaré sur https://status.scaleway.com/ :
[DEDIBOX] - Switch down in AMS1 Hall 6 rack B53
Resolved - This incident is resolved
Apr 25, 14:28 CEST
Investigating - Dedibox switch located in AMS1 Hall 6 rack B53 is currently down
Apr 25, 10:20 CEST
Le support m'a dit qu'il n'y a aucun lien entre cette panne et la panne matérielle de mon serveur.
J'en doute 🤔.
Je ne suis pas surpris de cette panne, d'après mes souvenirs, cette machine était reconditionnée, très vieille, j'avais bien conscience qu'une panne pouvait arriver à tout moment.
C'est la première fois que j'ai ce type de panne définitive depuis que j'utilise des serveurs dédiés Dedibox Scaleway, depuis 2006.
Au passage, j'ai perdu tout mon contenu de https://stats.sklein.xyz/
Amazon Relational Database Service (RDS)
Article Wikipedia : https://en.wikipedia.org/wiki/Amazon_Relational_Database_Service
Article Wikipedia : https://en.wikipedia.org/wiki/Bare-metal_server
Object Storage est généralement un service "cloud" de stockage qui permet de stocker des fichiers dans une structure plate, basée sur des IDs.
Object Storage permet de stocker une quantité de données quasi illimitée et un accès via une API REST.
L'API Amazon S3 s'est imposée comme la norme de facto dans ce domaine. Par abus de langage, la majorité des personnes utilisent le terme "stockage S3" à la place de Object Storage.
À ma connaissance, tous les services d'Object Storage proposent une API compatible S3.
- Amazon S3
- Backblaze
- Scaleway Object Storage
- Storj
- Azure Blob Storage
- Minio (solution self hosted)
- Azurite (uniquement en mode développement)
- Ceph via RADOS (solution self hosted)
La méthode Write Once Read Many ou encore nommé append-only est un concept de stockage où les données, une fois écrites, ne peuvent plus être modifiées ou supprimées pendant une période déterminée. Cette méthode garantit l'immutabilité des données sauvegardées.
Avantages principaux :
- Protection contre les ransomwares : les données en WORM ne peuvent pas être chiffrées ou modifiées par des logiciels malveillants
- Conformité réglementaire : répond aux exigences de diverses réglementations (GDPR, HIPAA, SOX) qui demandent une conservation immuable des données
- Preuve légale : fournit des preuves numériques non altérables pour les litiges ou les audits
- Protection contre les erreurs humaines : empêche la suppression accidentelle ou intentionnelle des données
Quelques services qui supportent Write Once Read Many :
Quelques extraits d'usage de ces termes :
Many cloud storage providers provide the ability to limit access as append-only. This feature is especially important to mitigate the risk of data loss for backup policies in the event that the computer being backed-up becomes infected with ransomware capable of deleting or encrypting the computer's backups.
To prevent a compromised backup client from deleting its backups (for example due to a ransomware infection), a repository service/backend can serve the repository in a so-called append-only mode.
The object lock feature allows users to lock objects and prevent them from being deleted or overwritten. Objects can be put on lock for a specific amount of time or indefinitely. The lock period is defined by the user.
The feature uses a write-once-read-many (WORM) data protection model. This model is generally used in cases where data must not be altered once it has been written. It provides regulatory compliance and protection against ransomware, and malicious or accidental deletion of objects.
Dernière page.