Editing
Paper/fr
(section)
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Fonctionnalités et documentation additionnelle == === Unification === L'un des objectifs centraux de Linux-VServer est de réduire l'utilisation des ressources partout ou cela est possible. Une excellente idée a donc germé, celle de partager des fichiers à travers les différents contextes sans interférer avec les taches administratives classiques ou diminuer le niveau de sécurité. Les fichiers communs à plusieurs contextes, peu sujet à être modifiés, comme les bibliothèques ou les binaires, peuvent être soudés via un lien dur sur un système de fichier partagé, réduisant d'autant le besoin en espace disque, cache d'inodes, et surtout, l'occupation mémoire, via l'utilisation des bibliothèques partagées. Seul inconvénient, si nous ne prenons pas quelques mesures supplémentaires, un contexte malicieux sera en mesure, par accident ou volontairement, de détruire ou modifier un tel fichier partagé, ce qui aurait des conséquences directes sur les autres contextes. La première étape consiste à placer sur les fichiers partagés un drapeau Immutable (et enlever la caps qui permet de modifier un tel fichier). Il faut toutefois ajouter un attribut supplémentaire à ces fichiers partagés, pour permettre leur suppréssion, lors, par exemple, d'une mise à jour des bibliothèques dans un l'un des contextes. Ces fichiers liés, immutables, que l'ont peut toutefois détruire, et appartenant à plus d'un contexte sont appelés unifiés, et l'action qui consiste à les rechercher et les préparer s'appelle Unification. Choississez l'unification si vous souhaitez réduire votre usage de ressources. L'inconvénient évident est une administration moins facile. Un Serveur Linux s'installe typiquement sur 500Mo de disque, et 10 serveurs unifiés en consommeront donc seulement 700Mo, et moins de mémoire pour les caches. Voir Exemple [XX] === Espaces de nom privés === Ajoutés récemment dans Linux-VServer, les espaces de noms privés utilisent la couche VFS du noyau linux et offrent une vue différente du système de fichier pour chaque contexte. Par rapport au schéma traditionnel, l'avantage principal apparait lorsqu'on modifie quelquechose dans un espace de nommage (par exemple, les points de montage); à cet instant, les autres contextes resteront intact, y compris biensur le contexte Hôte. Désavantage évident d'une telle approche; entrer dans un tel espace de noms privé n'est pas aussi simple que d'entrer dans un chroot. Toutefois, les choses pourraient changer dans les noyaux futurs, si cette fonctionnalité est par exemple intégrée directement à la fonction chroot(). === Le système de fichier Proc-FS de Linux-VServer === A structured, dynamically generated subtree of the well-known Proc-FS - actually two of them - has been created to allow for inspecting the different values of Security and Network Contexts. /proc/virtual .../info /proc/virtual/<pid> .../info .../status .../sched .../cvirt .../cacct .../limit === Extensions Token Bucket === While the basic idea of Linux-VServer is a peaceful coexistence of all contexts, sharing the common resources in a respectful way, it is sometimes useful to control the resource distribution for resource hungry processes. The basic principle of a Token Bucket is not very new. It is given here as an example for the Hard CPU Limit. The same principle also applies to scheduler priorities, network bandwidth limitation and resource control in general. The Hard CPU Limit uses this mechanism in the following way: consider a bucket of a certain size S which is filled with a specified amount of tokens R every interval T, until the bucket is "full" - excess tokens are spilled. At each timer tick, a running process consumes exactly one token from the bucket, unless the bucket is empty, in which case the process is put on a hold queue until the bucket has been refilled with a minimum M of tokens. The process is then rescheduled. A major advantage of a Token Bucket is that a certain amount of tokens can be accumulated in times of quiescence, which later can be used to burst when resources are required. Where a per-process Token Bucket would allow for a CPU resource limitation of a single process, a Context Token Bucket allows to control the CPU usage of all confined processes. Another approach, which is also implemented, is to use the current fill level of the bucket to adjust the process priority, thus reducing the priority of processes belonging to excessive contexts. Voir Exemple [XX] === Limites Disque par Contexte === Pour faire usage de cette fonctionnalité, le support pour les fichiers étiquetés XID doit être présent. Grace aux limites par contexte, vous pouvez alors régler une limite différente pour chaque contexte d'une partition partagée. Chaque block et inode d'un système de fichier est comptabilisé, dès lors qu'un hachage XID a été ajouté à ce système de fichier dans ce contexte donné. Those values, including current usage, maximum and reserved space, will be shown for filesystem queries, creating the illusion that the shared filesystem has a different usage and size, for each context. === Quota par Contexte === Similar to the Context Disk Limits, Per-Context Quota uses separate quota hashes for different Contexts on a shared filesystem. This is not required to allow for Linux-VServer quota on separate partitions. === Le périphérique "proxy" VRoot === Les opérations sur les Quotas (ioctls) nécessitent un accès aux périphériques de bloc. Ils ne sont donc pas disponible dans un VPS. === Stealth === Pour certaines applications, par exemple la préparation d'un "pot de miel" (honey-pot), ou d'une imitation particulièrement réaliste d'un vrai serveur à des fins éducatives, vous aurez peut-être besoin de confondre le contexte du serveur hôte (réel) et celui de votre pot de miel. Toutefois, certaines alternatives libres comme QEMU ou UML vous permettent de faire la même chose beaucoup mieux et avec moins d'efforts. Ce n'est donc pas une question centrale dans le développement de Linux-VServer.
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information