DOCSLIB.ORG

Sessions for Docker and Kubernetes Docker

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Sessions for Docker and Kubernetes Docker Sessions for Docker and Kubernetes Docker History from Chroot to Docker ● https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016 ● https://dzone.com/articles/evolution-of-linux-containers-future ​ What is Docker ● https://docs.docker.com/engine/faq/ ● LXC or runc (Open Container Specification) + AUFS/OverlayFS + Linux Namespaces + Control Groups What are LXC and Control Groups ● https://www.upguard.com/articles/docker-vs-lxc ● https://docs.docker.com/engine/faq/ ● https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups-cgroups ● https://sysadmincasts.com/episodes/24-introduction-to-containers-on-linux-using-lxc What are Namespaces ● https://blogs.rdoproject.org/7761/hands-on-linux-sandbox-with-namespaces-and-cgroups ● Section of Docker Network Example in https://github.com/gravitational/workshop/blob/master/k8snet.m What are Docker layers (OverlayFS/AUFS) ● http://blog.programster.org/overlayfs ● https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/ ● https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/ Docker 101 Workshop Docker Basics VM vs Container Components of Docker ● Docker Daemon o Manages complete container lifecycle and images on docker host. ● Docker Command Line o Allows interaction with docker daemon o Allows creation and management of containers and images o Allows interaction with docker registry ● Docker Registry o “Repository” of docker “images” used in creating “containers” Docker Objects ● Docker Images o Templates of creating containers o “Layered” o Managed on local and on remote registries ● Docker Containers o Actual running instances of “images” o Combination of “namespaces”, ”control groups (cgroups)” , “capabilities”, UnionFS etc Docker built on Multiple Linux subsystems ​ ● Linux Namespaces(runc) o NET namespace creates a separate networking stack for the container, with its own routing tables and devices o PID namespace is used to assign isolated process IDs that are separate from host OS. For example, this is important if we want to send signals to a running process. o MNT namespace creates a scoped view of a filesystem using VFS. It Let’s a container to get its ​ ​ own "root" filesystem and map directories from one location on the host to the other location inside container. o UTS namespace Let’s container to get to its own hostname. o IPC namespace is used to isolate inter-process communication (e.g. message queues). o USER namespace allows container processes have different users and IDs from the host OS. ● Control Groups (cgroups) o Kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, etc.) ● Capabilities o Capabilities provide enhanced permission checks on the running process, and can limit the interface configuration, even for a root user - for example (CAP_NET_ADMIN) ● Union file system(AUFS) o Docker Engine uses UnionFS to provide the building blocks for containers. Docker Engine can use multiple UnionFS variants, including AUFS, btrfs, vfs, and DeviceMapper Docker Workshop ● Install docker o Prefer to use Ubuntu 16.04 (avoid Ubuntu 14.04 as lot of kernel updates for docker not present) o apt-get install docker.io o Note : docker.io is a Ubuntu provided package and docker-ce is the community version of docker Ubuntu package ● Let’s Check a few things about the installed docker o docker info o docker version ● Check if Docker is running as expected o docker run hello-world o The first time you run this it will download the hello-world image from docker hub and later it will use the cached image for further reruns. ● If not working set HTTP_PROXY and HTTPS_PROXY o place the above env variables in docker.service or /etc/docker/default o Prefer using systemctl instead of service ● Run commands on docker containers o docker run busybox echo “Hello World” o Let’s see processes within the container ▪ docker run busybox ps aux o Let’s see environment variables in container ▪ docker run busybox env o Let’s view the folder without any external mounts ▪ docker run busybox ls -l /home o Let’s view the folder with host directory mounted inside the container ▪ docker run -v $PWD:/home busybox ls -l /home o Let’s view the network interfaces in docker container ▪ docker run busybox ifconfig -a o Let’s setup port forward from host to container and run an http service in container ▪ docker run -p 5000:5000 library/python:3.3 python -m http.server 5000 ▪ From host ▪ curl http://localhost:5000 ​ o Let’s Run Containers as daemons ▪ docker run -d -p 5000:5000 --name=simple1 library/python:3.3 python -m http.server 5000 ▪ Essential point : As soon as the main process with container is closed , container is killed. o Let’s see container detail ▪ docker ps o Let’s see more container detail ▪ docker inspect <Container ID> o Let’s see container logs ▪ docker logs <Container ID> o Let’s attach to running container ▪ docker exec -ti mycontainer /bin/bash ▪ Please note that container should have the /bin/bash binary ▪ For security its possible that the container does not have bash or sh binary Docker Ecosystem ● Docker Engine o “Core” of docker ● Docker Machine o Creates/provisions docker “hosts” in various clouds such as Azure, AWS including vagrant ● Docker Swarm o Manages multiple docker hosts. ● Docker Compose o Helps assemble applications using multiple docker containers Docker Engine Components ● Docker Engine o ContainerD ▪ Manages container/images lifecycle ▪ Uses RunC to create containers ▪ Supports Open Container Interface format(Namespaces+CGroups+Capablities+UnionFS) ​ ​ ​ ​ ​ ​ o RunC ▪ Runtime for running containers Deep Dive on Linux Namespaces https://blog.yadutaf.fr/2013/12/22/introduction-to-linux-namespaces-part-1-uts/ Deep Dive on Control Groups http://www.fernandoalmeida.net/blog/how-to-limit-cpu-and-memory-usage-with-cgroups-on-debian-ubuntu/ Docker 102 Workshop Docker Basics – Building Images ● Build Apache Service Container via dockerfile ● Create a new directory o mkdir docker-apache ● Create a Dockerfile in the above created folder FROM alpine:3.3 RUN apk --update add apache2 && rm -rf /var/cache/apk/* RUN mkdir -p /run/apache2 EXPOSE 80 CMD httpd -D FOREGROUND ● Build the container o docker build –t docker-apache . ▪ Please note the (.) at the end of the line ● Let’s run the container o docker run –d –p 2803:80 docker-apache ● Let’s try and get a page from host o curl http://localhost:2803 Docker 103 Workshop Docker Basics – Networking Docker Built-In Network Options ● Bridge — The bridge driver creates a Linux bridge on the host that is managed by Docker. By default ​ containers on a bridge will be able to communicate with each other. External access to containers can also be configured through the bridge driver. ● Overlay — The overlay driver creates an overlay network that supports multi-host networks out of the box. ​ It uses a combination of local Linux bridges and VXLAN to overlay container-to-container communications over physical network infrastructure. ● MACVLAN — The macvlan driver uses the MACVLAN bridge mode to establish a connection between ​ container interfaces and a parent host interface (or sub-interfaces). It can be used to provide IP addresses to containers that are routable on the physical network. Additionally VLANs can be trunked to the macvlan driver to enforce Layer 2 container segmentation. ● Host — With the host driver, a container uses the networking stack of the host. There is no namespace ​ separation, and all interfaces on the host can be used directly by the container. ● None — The none driver gives a container its own networking stack and network namespace but does not ​ configure interfaces inside the container. Without additional configuration, the container is completely isolated from the host networking stack. Docker Network Model ● Explore Docker Networking o List Docker Network Options ▪ docker network ls o Inspect Network ▪ Docker network inspect <name> $ docker network ls NETWORK ID NAME DRIVER SCOPE 1befe23acd58 bridge bridge local 726ead8f4e6b host host local ef4896538cc7 none null local # Install the brctl tools $ apt-get install bridge-utils <Snip> # List the bridges on your Docker host $ brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242f17f89a6 no $ ip a <Snip> 3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:f1:7f:89:a6 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 scope global docker0 valid_lft forever preferred_lft forever inet6 fe80::42:f1ff:fe7f:89a6/64 scope link valid_lft forever preferred_lft forever $ docker run -dt ubuntu sleep infinity 6dd93d6cdc806df6c7812b6202f6096e43d9a013e56e5e638ee4bfb4ae8779ce ​ $ brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242f17f89a6 no veth3a080f $ docker network inspect bridge <Snip> "Containers": { "6dd93d6cdc806df6c7812b6202f6096e43d9a013e56e5e638ee4bfb4ae8779ce": { ​ ​ "Name": "reverent_dubinsky", "EndpointID": "dda76da5577960b30492fdf1526c7dd7924725e5d654bed57b44e1a6e85e956c", "MacAddress": "02:42:ac:11:00:02", "IPv4Address": "172.17.0.2/16", "IPv6Address": "" } }, <Snip> $ ping 172.17.0.2 64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.069 ms 64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.052 ms 64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.050 ms 64 bytes from 172.17.0.2: icmp_seq=4 ttl=64 time=0.049 ms 64 bytes from 172.17.0.2: icmp_seq=5 ttl=64 time=0.049 ms ^C --- 172.17.0.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.049/0.053/0.069/0.012 ms Docker 104 Workshop Docker Basics – Storage(revisited) What does “Docker uses Layers mean”? ● Image is combination of layers ● The running “container” basically means having a “Thin RW Layer” linked to “Image”. o All edits and changes go to the “Thin RW Layer” o Once the container is removed the changes are also gone ● Multiple containers (Thin RW Layers) point to just one “Image”, saving on-disk size.
Load more

Recommended publications
  • CERIAS Tech Report 2017-5 Deceptive Memory Systems by Christopher N
    CERIAS Tech Report 2017-5 Deceptive Memory Systems by Christopher N. Gutierrez Center for Education and Research Information Assurance and Security Purdue University, West Lafayette, IN 47907-2086 DECEPTIVE MEMORY SYSTEMS ADissertation Submitted to the Faculty of Purdue University by Christopher N. Gutierrez In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy December 2017 Purdue University West Lafayette, Indiana ii THE PURDUE UNIVERSITY GRADUATE SCHOOL STATEMENT OF DISSERTATION APPROVAL Dr. Eugene H. Spa↵ord, Co-Chair Department of Computer Science Dr. Saurabh Bagchi, Co-Chair Department of Computer Science Dr. Dongyan Xu Department of Computer Science Dr. Mathias Payer Department of Computer Science Approved by: Dr. Voicu Popescu by Dr. William J. Gorman Head of the Graduate Program iii This work is dedicated to my wife, Gina. Thank you for all of your love and support. The moon awaits us. iv ACKNOWLEDGMENTS Iwould liketothank ProfessorsEugeneSpa↵ord and SaurabhBagchi for their guidance, support, and advice throughout my time at Purdue. Both have been instru­ mental in my development as a computer scientist, and I am forever grateful. I would also like to thank the Center for Education and Research in Information Assurance and Security (CERIAS) for fostering a multidisciplinary security culture in which I had the privilege to be part of. Special thanks to Adam Hammer and Ronald Cas­ tongia for their technical support and Thomas Yurek for his programming assistance for the experimental evaluation. I am grateful for the valuable feedback provided by the members of my thesis committee, Professor Dongyen Xu, and Professor Math­ ias Payer.
    [Show full text]
  • HTTP-FUSE Xenoppix
    HTTP-FUSE Xenoppix Kuniyasu Suzaki† Toshiki Yagi† Kengo Iijima† Kenji Kitagawa†† Shuichi Tashiro††† National Institute of Advanced Industrial Science and Technology† Alpha Systems Inc.†† Information-Technology Promotion Agency, Japan††† {k.suzaki,yagi-toshiki,k-iijima}@aist.go.jp [email protected], [email protected] Abstract a CD-ROM. Furthermore it requires remaking the entire CD-ROM when a bit of data is up- dated. The other solution is a Virtual Machine We developed “HTTP-FUSE Xenoppix” which which enables us to install many OSes and ap- boots Linux, Plan9, and NetBSD on Virtual plications easily. However, that requires in- Machine Monitor “Xen” with a small bootable stalling virtual machine software. (6.5MB) CD-ROM. The bootable CD-ROM in- cludes boot loader, kernel, and miniroot only We have developed “Xenoppix” [1], which and most part of files are obtained via Internet is a combination of CD/DVD bootable Linux with network loopback device HTTP-FUSE “KNOPPIX” [2] and Virtual Machine Monitor CLOOP. It is made from cloop (Compressed “Xen” [3, 4]. Xenoppix boots Linux (KNOP- Loopback block device) and FUSE (Filesys- PIX) as Host OS and NetBSD or Plan9 as Guest tem USErspace). HTTP-FUSE CLOOP can re- OS with a bootable DVD only. KNOPPIX construct a block device from many small block is advanced in automatic device detection and files of HTTP servers. In this paper we describe driver integration. It prepares the Xen environ- the detail of the implementation and its perfor- ment and Guest OSes don’t need to worry about mance. lack of device drivers.
    [Show full text]
  • How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise
    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise Abstract This paper will document a process to create a custom Live CD for secure remote incident handling on Windows and Linux systems. The process will include how to configure SSH for remote access to the Live CD even when running behind a NAT device. The combination of customization and secure remote access will make this process valuable to incident handlers working in enterprise environments with limited remote IT support. Bert Hayes, [email protected] How to Create a Custom Live CD for Remote Incident Handling 2 Table of Contents Abstract ...........................................................................................................................................1 1. Introduction ............................................................................................................................5 2. Making Your Own Customized Debian GNU/Linux Based System........................................7 2.1. The Development Environment ......................................................................................7 2.2. Making Your Dream Incident Handling System...............................................................9 2.3. Hardening the Base Install.............................................................................................11 2.3.1. Managing Root Access with Sudo..........................................................................11 2.4. Randomizing the Handler Password at Boot Time ........................................................12
    [Show full text]
  • In Search of the Ideal Storage Configuration for Docker Containers
    In Search of the Ideal Storage Configuration for Docker Containers Vasily Tarasov1, Lukas Rupprecht1, Dimitris Skourtis1, Amit Warke1, Dean Hildebrand1 Mohamed Mohamed1, Nagapramod Mandagere1, Wenji Li2, Raju Rangaswami3, Ming Zhao2 1IBM Research—Almaden 2Arizona State University 3Florida International University Abstract—Containers are a widely successful technology today every running container. This would cause a great burden on popularized by Docker. Containers improve system utilization by the I/O subsystem and make container start time unacceptably increasing workload density. Docker containers enable seamless high for many workloads. As a result, copy-on-write (CoW) deployment of workloads across development, test, and produc- tion environments. Docker’s unique approach to data manage- storage and storage snapshots are popularly used and images ment, which involves frequent snapshot creation and removal, are structured in layers. A layer consists of a set of files and presents a new set of exciting challenges for storage systems. At layers with the same content can be shared across images, the same time, storage management for Docker containers has reducing the amount of storage required to run containers. remained largely unexplored with a dizzying array of solution With Docker, one can choose Aufs [6], Overlay2 [7], choices and configuration options. In this paper we unravel the multi-faceted nature of Docker storage and demonstrate its Btrfs [8], or device-mapper (dm) [9] as storage drivers which impact on system and workload performance. As we uncover provide the required snapshotting and CoW capabilities for new properties of the popular Docker storage drivers, this is a images. None of these solutions, however, were designed with sobering reminder that widespread use of new technologies can Docker in mind and their effectiveness for Docker has not been often precede their careful evaluation.
    [Show full text]
  • Understanding the Performance of Container Execution Environments
    Understanding the performance of container execution environments Guillaume Everarts de Velp, Etienne Rivière and Ramin Sadre [email protected] EPL, ICTEAM, UCLouvain, Belgium Abstract example is an automatic grading platform named INGIn- Many application server backends leverage container tech- ious [2, 3]. This platform is used extensively at UCLouvain nologies to support workloads formed of short-lived, but and other institutions around the world to provide computer potentially I/O-intensive, operations. The latency at which science and engineering students with automated feedback container-supported operations complete impacts both the on programming assignments, through the execution of se- users’ experience and the throughput that the platform can ries of unit tests prepared by instructors. It is necessary that achieve. This latency is a result of both the bootstrap and the student code and the testing runtime run in isolation from execution time of the containers and is impacted greatly by each others. Containers answer this need perfectly: They the performance of the I/O subsystem. Configuring appro- allow students’ code to run in a controlled and reproducible priately the container environment and technology stack environment while reducing risks related to ill-behaved or to obtain good performance is not an easy task, due to the even malicious code. variety of options, and poor visibility on their interactions. Service latency is often the most important criteria for We present in this paper a benchmarking tool for the selecting a container execution environment. Slow response multi-parametric study of container bootstrap time and I/O times can impair the usability of an edge computing infras- performance, allowing us to understand such interactions tructure, or result in students frustration in the case of IN- within a controlled environment.
    [Show full text]
  • Container-Based Virtualization for Byte-Addressable NVM Data Storage
    2016 IEEE International Conference on Big Data (Big Data) Container-Based Virtualization for Byte-Addressable NVM Data Storage Ellis R. Giles Rice University Houston, Texas [email protected] Abstract—Container based virtualization is rapidly growing Storage Class Memory, or SCM, is an exciting new in popularity for cloud deployments and applications as a memory technology with the potential of replacing hard virtualization alternative due to the ease of deployment cou- drives and SSDs as it offers high-speed, byte-addressable pled with high-performance. Emerging byte-addressable, non- volatile memories, commonly called Storage Class Memory or persistence on the main memory bus. Several technologies SCM, technologies are promising both byte-addressability and are currently under research and development, each with dif- persistence near DRAM speeds operating on the main memory ferent performance, durability, and capacity characteristics. bus. These new memory alternatives open up a new realm of These include a ReRAM by Micron and Sony, a slower, but applications that no longer have to rely on slow, block-based very large capacity Phase Change Memory or PCM by Mi- persistence, but can rather operate directly on persistent data using ordinary loads and stores through the cache hierarchy cron and others, and a fast, smaller spin-torque ST-MRAM coupled with transaction techniques. by Everspin. High-speed, byte-addressable persistence will However, SCM presents a new challenge for container-based give rise to new applications that no longer have to rely on applications, which typically access persistent data through slow, block based storage devices and to serialize data for layers of block based file isolation.
    [Show full text]
  • DMFS - a Data Migration File System for Netbsd
    DMFS - A Data Migration File System for NetBSD William Studenmund Veridian MRJ Technology Solutions NASAAmes Research Center" Abstract It was designed to support the mass storage systems de- ployed here at NAS under the NAStore 2 system. That system supported a total of twenty StorageTek NearLine ! have recently developed DMFS, a Data Migration File tape silos at two locations, each with up to four tape System, for NetBSD[I]. This file system provides ker- drives each. Each silo contained upwards of 5000 tapes, nel support for the data migration system being devel- and had robotic pass-throughs to adjoining silos. oped by my research group at NASA/Ames. The file system utilizes an underlying file store to provide the file The volman system is designed using a client-server backing, and coordinates user and system access to the model, and consists of three main components: the vol- files. It stores its internal metadata in a flat file, which man master, possibly multiple volman servers, and vol- resides on a separate file system. This paper will first man clients. The volman servers connect to each tape describe our data migration system to provide a context silo, mount and unmount tapes at the direction of the for DMFS, then it will describe DMFS. It also will de- volman master, and provide tape services to clients. The scribe the changes to NetBSD needed to make DMFS volman master maintains a database of known tapes and work. Then it will give an overview of the file archival locations, and directs the tape servers to move and mount and restoration procedures, and describe how some typi- tapes to service client requests.
    [Show full text]
  • Unionfs: User- and Community-Oriented Development of a Unification File System
    Unionfs: User- and Community-Oriented Development of a Unification File System David Quigley, Josef Sipek, Charles P. Wright, and Erez Zadok Stony Brook University {dquigley,jsipek,cwright,ezk}@cs.sunysb.edu Abstract If a file exists in multiple branches, the user sees only the copy in the higher-priority branch. Unionfs allows some branches to be read-only, Unionfs is a stackable file system that virtually but as long as the highest-priority branch is merges a set of directories (called branches) read-write, Unionfs uses copy-on-write seman- into a single logical view. Each branch is as- tics to provide an illusion that all branches are signed a priority and may be either read-only writable. This feature allows Live-CD develop- or read-write. When the highest priority branch ers to give their users a writable system based is writable, Unionfs provides copy-on-write se- on read-only media. mantics for read-only branches. These copy- on-write semantics have lead to widespread There are many uses for namespace unifica- use of Unionfs by LiveCD projects including tion. The two most common uses are Live- Knoppix and SLAX. In this paper we describe CDs and diskless/NFS-root clients. On Live- our experiences distributing and maintaining CDs, by definition, the data is stored on a read- an out-of-kernel module since November 2004. only medium. However, it is very convenient As of March 2006 Unionfs has been down- for users to be able to modify the data. Uni- loaded by over 6,700 unique users and is used fying the read-only CD with a writable RAM by over two dozen other projects.
    [Show full text]
  • We Get Letters Sept/Oct 2018
    SEE TEXT ONLY WeGetletters by Michael W Lucas letters@ freebsdjournal.org tmpfs, or be careful to monitor tmpfs space use. Hey, FJ Letters Dude, Not that you’ll configure your monitoring system Which filesystem should I use? to watch tmpfs, because it’s temporary. And no matter what, one day you’ll forget —FreeBSD Newbie that you used memory space as a filesystem. You’ll stash something vital in that temporary space, then reboot. And get really annoyed Dear FreeBSD Newbie, when that vital data vanishes into the ether. First off, welcome to FreeBSD. The wider com- Some other filesystems aren’t actively terrible. munity is glad to help you. The device filesystem devfs(5) provides device Second, please let me know who told you to nodes. Filesystems that can’t store user data are start off by writing me. I need to properly… the best filesystems. But then some clever sysad- “thank” them. min decides to hack on /etc/devfs.rules to Filesystems? Sure, let’s talk filesystems. change the standard device nodes for their spe- Discussing which filesystem is the worst is like cial application, or /etc/devd.conf to create or debating the merits of two-handed swords as reconfigure device nodes, and the whole system compared to lumberjack-grade chainsaws and goes down the tubes. industrial tulip presses. While every one of them Speaking of clever sysadmins, now and then has perfectly legitimate uses, in the hands of the people decide that they want to optimize disk novice they’re far more likely to maim everyone space or cut down how many copies of a file involved.
    [Show full text]
  • Ubuntu Server Guide Basic Installation Preparing to Install
    Ubuntu Server Guide Welcome to the Ubuntu Server Guide! This site includes information on using Ubuntu Server for the latest LTS release, Ubuntu 20.04 LTS (Focal Fossa). For an offline version as well as versions for previous releases see below. Improving the Documentation If you find any errors or have suggestions for improvements to pages, please use the link at thebottomof each topic titled: “Help improve this document in the forum.” This link will take you to the Server Discourse forum for the specific page you are viewing. There you can share your comments or let us know aboutbugs with any page. PDFs and Previous Releases Below are links to the previous Ubuntu Server release server guides as well as an offline copy of the current version of this site: Ubuntu 20.04 LTS (Focal Fossa): PDF Ubuntu 18.04 LTS (Bionic Beaver): Web and PDF Ubuntu 16.04 LTS (Xenial Xerus): Web and PDF Support There are a couple of different ways that the Ubuntu Server edition is supported: commercial support and community support. The main commercial support (and development funding) is available from Canonical, Ltd. They supply reasonably- priced support contracts on a per desktop or per-server basis. For more information see the Ubuntu Advantage page. Community support is also provided by dedicated individuals and companies that wish to make Ubuntu the best distribution possible. Support is provided through multiple mailing lists, IRC channels, forums, blogs, wikis, etc. The large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions.
    [Show full text]
  • Scibian 9 HPC Installation Guide
    Scibian 9 HPC Installation guide CCN-HPC Version 1.9, 2018-08-20 Table of Contents About this document . 1 Purpose . 2 Structure . 3 Typographic conventions . 4 Build dependencies . 5 License . 6 Authors . 7 Reference architecture. 8 1. Hardware architecture . 9 1.1. Networks . 9 1.2. Infrastructure cluster. 10 1.3. User-space cluster . 12 1.4. Storage system . 12 2. External services . 13 2.1. Base services. 13 2.2. Optional services . 14 3. Software architecture . 15 3.1. Overview . 15 3.2. Base Services . 16 3.3. Additional Services. 19 3.4. High-Availability . 20 4. Conventions . 23 5. Advanced Topics . 24 5.1. Boot sequence . 24 5.2. iPXE Bootmenu Generator. 28 5.3. Debian Installer Preseed Generator. 30 5.4. Frontend nodes: SSH load-balancing and high-availability . 31 5.5. Service nodes: DNS load-balancing and high-availability . 34 5.6. Consul and DNS integration. 35 5.7. Scibian diskless initrd . 37 Installation procedure. 39 6. Overview. 40 7. Requirements . 41 8. Temporary installation node . 44 8.1. Base installation . 44 8.2. Administration environment . 44 9. Internal configuration repository . 46 9.1. Base directories . 46 9.2. Organization settings . 46 9.3. Cluster directories . 48 9.4. Puppet configuration . 48 9.5. Cluster definition. 49 9.6. Service role . 55 9.7. Authentication and encryption keys . 56 10. Generic service nodes . 62 10.1. Temporary installation services . 62 10.2. First Run. 62 10.3. Second Run . 64 10.4. Base system installation. 64 10.5. Ceph deployment . 66 10.6. Consul deployment.
    [Show full text]
  • LSF ’07: 2007 Linux Storage & Filesystem Workshop Namically Adjusted According to the Current Popularity of Its Hot Zone
    June07login1summaries_press.qxd:login summaries 5/27/07 10:27 AM Page 84 PRO: A Popularity-Based Multi-Threaded Reconstruction overhead of PRO is O(n), although if a priority queue is Optimization for RAID-Structured Storage Systems used in the PRO algorithm the computation overhead can Lei Tian and Dan Feng, Huazhong University of Science and be reduced to O(log n). The entire PRO implementation in Technology; Hong Jiang, University of Nebraska—Lincoln; Ke the RAIDFrame software only added 686 lines of code. Zhou, Lingfang Zeng, Jianxi Chen, and Zhikun Wang, Hua- Work on PRO is ongoing. Future work includes optimiz - zhong University of Science and Technology and Wuhan ing the time slice, scheduling strategies, and hot zone National Laboratory for Optoelectronics; Zhenlei Song, length. Currently, PRO is being ported into the Linux soft - Huazhong University of Science and Technology ware RAID. Finally, the authors plan on further investigat - ing use of access patterns to help predict user accesses and Hong Jiang began his talk by discussing the importance of of filesystem semantic knowledge to explore accurate re - data recovery. Disk failures have become more common in construction. RAID-structured storage systems. The improvement in disk capacity has far outpaced improvements in disk band - The first questioner asked about the average rate of recov - width, lengthening the overall RAID recovery time. Also, ery for PRO. Hong answered that the average reconstruc - disk drive reliability has improved slowly, resulting in a tion time is several hundred seconds in the experimental very high overall failure rate in a large-scale RAID storage setup.
    [Show full text]