DOCSLIB.ORG

Software Distribution with Cernvm-FS Webapi Jakob Blomer CERN, EP-SFT [email protected] 2019-05-17 Micro Agent Cloud

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Distribution with Cernvm-FS Webapi Jakob Blomer CERN, EP-SFT Jblomer@Cern.Ch 2019-05-17 Micro Agent Cloud Agent Cloud Book Keeper Gateway Software Distribution with CernVM-FS WebAPI Jakob Blomer CERN, EP-SFT [email protected] https://github.com/cvmfs/cvmfs 2019-05-17 Micro Agent Cloud 1. Accelerate. Book Keeper Gateway WebAPI Micro 1 Agent Cloud 2. Collide. Book Keeper Gateway WebAPI Micro 2 Agent Cloud 3. Measure. Book Keeper Gateway ∙ Billions of independent “events” WebAPI ∙ Each event subject to complex software processing → High-Throughput Computing Micro 3 Agent Cloud 4. Analyze! Book Keeper Gateway WebAPI Micro 4 Agent Cloud Computing, Federated Book Keeper Gateway ∙ Physics and computing: international collaborations ∙ “The Grid”: ∼160 data centers ∙ Approx.: global batch system WebAPI Micro 5 Agent Cloud Software Delivery by a File System ¶ Provide uniform, consistent, and versioned POSIX file system access to /cvmfs Book Keeper $ ls /cvmfs/cms.cern.ch slc7_amd64_gcc700 slc7_ppc64le_gcc530 slc7_aarch64_gcc700 slc6_mic_gcc481 ... on grids, clouds, supercomputers and end user laptops Gateway read publish WebAPI · Populate and propagate new and updated content ∙ A few “software librarians” can publish into /cvmfs ∙ Transactional writes as in git commit/push Micro 6 Agent Cloud Scale of Deployment Book Keeper Gateway WebAPI ∙ > 1 billion files under management ∙ HTTP data transport ∙ LHC infrastructure: Micro 5 mirror servers, 400 web caches 7 Agent Cloud Key Design Choices Book Keeper Transformation HTTP Transport a1240 Caching & Replication 41ae3 ... 7e95b Gateway Read-Only Content-Addressed Objects, Read/Write File System Merkle Tree File System Worker Nodes Software Publisher / Master Source WebAPI ∙ Reading and writing treated asymmetrically ∙ HTTP transport + caching ∙ Immutable objects, stateless services ∙ Consistency over availability Micro 8 Agent Cloud Key Design Choices Book Keeper Transformation HTTP Transport a1240 Caching & Replication 41ae3 ... 7e95b Read-Only Several CDN options: Content-Addressed Objects, Read/Write Gateway File System Merkle Tree File System ∙ Apache + Squids ∙ Ceph/S3 Worker Nodes ∙ Commercial CDN Software Publisher / Master Source WebAPI ∙ Reading and writing treated asymmetrically ∙ HTTP transport + caching ∙ Immutable objects, stateless services ∙ Consistency over availability Micro 8 Agent Cloud Reading Book Keeper CernVM-FS rAA Basic System Utilities Global HTTP Cache Hierarchy Gateway Fuse OS Kernel File System CernVM-FS Repository (HTTP or S3) Memory Buffer Persistent Cache All Versions Available WebAPI ∼100 MB ∼20 GB 1 TB – 10 TB ∙ Fuse based, independent mount points, e. g. /cvmfs/atlas.cern.ch Micro ∙ High cache effiency because entire cluster likely to use same software 9 Agent Cloud Writing Book Keeper Staging Area CernVM-FS Read-Only AUFS ∙ Kernel-level union file system: (Union File System) AUFS, OverlayFS Read/Write Gateway Interface File System, S3 WebAPI Publishing new content [ ~ ]# cvmfs_server transaction containers.cern.ch [ ~ ]# cd /cvmfs/containers.cern.ch && tar xvf ubuntu1610.tar.gz [ ~ ]# cvmfs_server publish containers.cern.ch Micro 10 Agent Cloud Use of Content-Addressable Storage /cvmfs/alice.cern.ch Object Store ∙ Compressed files and chunks Book Keeper amd64-gcc6.0 ∙ De-duplicated 4.2.0 ChangeLog . File Catalog . Gateway ∙ Directory structure, symlinks Compression, Hashing 806fbb67373e9... ∙ Content hashes of regular files ∙ Digitally signed WebAPI Repository ⇒ integrity, authenticity ∙ Time to live Object Store File catalogs ∙ Partitioned / Merkle hashes (possibility of sub catalogs) Micro 11 ⇒ Immutable files, trivial to check for corruption, versioning Why a file system? 12 Agent Cloud HEP Software Challenge Book Keeper Individual 0.1 MLOC Key Figures Analysis Code ∙ Hundreds of (novice) developers Gateway changing ∙ Hundred million binaries Experiment 4 MLOC Software Framework ∙ 1 TB / day of nightly builds ∙ ∼100 000 machines world-wide High Energy Physics 5 MLOC WebAPI Libraries ∙ Daily production releases, remain available “eternally” Compiler 20 MLOC System Libraries stable OS Kernel → too much for a packaging approach Micro 13 Agent Cloud Actual new content Software Directory Tree Book Keeper atlas.cern.ch 15 ] Directories repo 6 10 Symlinks × software Gateway 10 x86_64-gcc43 Duplicates 17.1.0 5 WebAPI File System Entries [ 17.2.0 . 1 File Kernel . Statistics over 2 Years Micro Between consecutive software versions: only ∼15 % new files At runtime only tiny fraction of files actually accessed 14 Agent Cloud Container Amplification Book Keeper Linux Libs ... Gateway ∙ Containers are easier to create than to role-out at scale WebAPI ∙ Ideally: containers for isolation and a software file system for distribution Micro 15 Agent Cloud Custom Graph Driver / Snapshotter Approach Book Keeper Gateway WebAPI Ideally: native support for (some) unpacked layers on a read-only file sytem Micro 16.
Load more

Recommended publications
  • 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]
  • 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]
  • Xrac: Execution and Access Control for Restricted Application Containers on Managed Hosts
    xRAC: Execution and Access Control for Restricted Application Containers on Managed Hosts Frederik Hauser, Mark Schmidt, and Michael Menth Chair of Communication Networks, University of Tuebingen, Tuebingen, Germany Email: {frederik.hauser,mark-thomas.schmidt,menth}@uni-tuebingen.de Abstract—We propose xRAC to permit users to run spe- or Internet access. That means, appropriate network control cial applications on managed hosts and to grant them access elements, e.g., firewalls or SDN controllers, may be informed to protected network resources. We use restricted application about authorized RACs and their needs. The authorized traffic containers (RACs) for that purpose. A RAC is a virtualization container with only a selected set of applications. Authentication can be identified by the RAC’s IPv6 address. We call this verifies the RAC user’s identity and the integrity of the RAC concept xRAC as it controls execution and access for RACs. image. If the user is permitted to use the RAC on a managed We mention a few use cases that may benefit from xRAC. host, launching the RAC is authorized and access to protected RACs may allow users to execute only up-to-date RAC network resources may be given, e.g., to internal networks, images. Execution of a RAC may be allowed only to special servers, or the Internet. xRAC simplifies traffic control as the traffic of a RAC has a unique IPv6 address so that it can users or user groups, e.g., to enforce license restrictions. be easily identified in the network. The architecture of xRAC Only selected users in a high-security area may get access to reuses standard technologies, protocols, and infrastructure.
    [Show full text]
  • How to Run Ubuntu, Chromiumos, Android at the Same Time on an Embedded Device
    How to run Ubuntu, ChromiumOS, Android at the Same Time on an Embedded Device Grégoire Gentil Founder Always Innovating Embedded Linux Conference April 2011 Why should I stay and attend this talk? ● Very cool demos that you have never seen before! ● Win some USB dongles and USB-to-HDMI adapters (Display Link inside, $59 value)!!! ● Come in front rows, you will better see the Pandaboard demo on multiple screens Objective of the talk ● Learn how to run multiple operating systems... ● AIOS (Angstrom fork), Ubuntu Maverick, Android Gingerbread, ChromiumOS ● …on a single ARM device (Beagleboard-xM, Pandaboard)... ● …at the same time, natively, with zero performance loss... ● …connected to one or multiple monitors simultaneously!!!! Where does it come from? (1/2) ● Hardware is becoming so versatile Where does it come from? (2/2) ● Open source is so fragmented ● => “Single” (between quote) Linux but with different userspace stacks How do we do it? ● Obviously: chroot ● Key lesson of this talk: simple theoretically, difficult to implement it right ● Kind of Rubik's cube puzzle – When assembling a face, you destroy the others ● Key issues along the way – Making work the core OS – Problem of managing output (video) – Problem of managing all inputs (HID, network) => End-up patching everything in kernel and OS Live Demo ChromiumOS Android AIOS Beagleboard xM TI OMAP3 Ubuntu AIOS ChromiumOS Android Pandaboard TI OMAP4 Multiple OS running side-by-side ● One kernel, multiple ARM native root file systems ● Hot-switchable at runtime ● Much faster than a usual virtual machine architecture AIOS Android Ubuntu Chromium Gentoo rootfs rootfs rootfs rootfs rootfs ..
    [Show full text]
  • Union Mounts
    Union mounts http://valerieaurora.org/union/ Valerie Aurora Red Hat, Inc. <[email protected]> Overview ● The problem ● Existing solutions ● Union mounts ● Why not unionfs? ● Limitations of unionfs ● What you can do ● How to take over the world with union mounts and Puppet What's the problem? ● Lots of nearly identical root file systems ● Virtual machines ● Any cluster ● LiveCD ● Could we share some of these? Ways to share file systems ● Copy-on-write (COW) block devices ● NFS-exported root file system ● Other network/cluster file systems ● Snapshots Why do we need union mounts? ● COW block device inefficient, divergent ● NFS server gets overloaded ● Cluster file system is needlessly heavyweight ● Snapshots are limited to a single system Solution: file-level sharing ● Take one read-only file system (shared) ● Add one local writable file system ● Lookups “fall through” to lower read-only fs ● Writes go to topmost writable fs ● Writes to lower fs trigger copy-up to topmost fs Sounds like... unionfs ● Unionfs and aufs panic the kernel ● Unionfs architecture is fundamentally broken ● Al Viro's canonical explanation here: http://lkml.indiana.edu/hypermail/linux/kernel/0802.0/0839.html ● University research project ● Unmerged for 7 years and counting Why union mounts is different ● Implemented in the VFS ● Designed with help of VFS maintainers ● Many fewer features Limitations of union mounts ● open(O_RDONLY) gets you a different file from open (O_RDWR) ● fchmod()/fchown()/futimensat() on fd don't work ● Only one writable layer ● Requires on-disk format changes to topmost fs What you can do ● Use open(O_RDONLY) ● Don't use fchmod()/fchown()/futimensat() on fd ● Don't access same file from multiple fds ● Let your engineers work on union mounts ● Review ● Test ● http://valerieaurora.org/union/ Puppet + Union mounts = World Domination Thank you Jan Blunck Miklos Szeredi Felix Fietkau Al Viro Erez Zadok Christoph Hellwig J.
    [Show full text]
  • Current Events in Container Storage
    Current Events in Container Storage Keith Hudgins Docker 2019 Storage Developer Conference. © Docker, Inc. All Rights Reserved. 1 Container Community Orgs ▪ Cloud Native Computing Foundation (CNCF) ▪ https://www.cncf.io/ ▪ Open Container Initiative (OCI) ▪ https://www.opencontainers.org/ ▪ Both are part of the Linux Foundation ▪ https://www.linuxfoundation.org/ 2019 Storage Developer Conference. © Docker, Inc. All Rights Reserved. 2 Container Runtimes ▪ Docker ▪ Default for most container installs, widest user base ▪ 20 million+ Docker Community Engine installs alone ▪ Containerd ▪ Fully graduated CNCF project (as of Feb 2019) ▪ Windows and Linux container runtime ▪ Upstream of Docker (for Linux, anyway) ▪ CoreOS (rkt) ▪ CoreOS acquired by RedHat May 2018 ▪ rkt archived by CNCF as of 8/16/2019 ▪ CRI-O ▪ Default runtime for RH OpenShift as of 4.0, June 2019 ▪ Intended to be Kubernetes-native runtime ▪ Fully open-source ▪ Upstream of these projects* are CNCF efforts. *Docker has non-CNCF upstream 3 2019 Storage Developer Conference. © Docker, Inc. All Rights Reserved. Components as well Container Storage Lifecycle 2019 Storage Developer Conference. © Docker, Inc. All Rights Reserved. 4 Container Storage Lifecycle (cont) ▪ Containers use storage in 3 primary contexts: ▪ Raw container image ▪ At rest, either as a file on disk or object storage ▪ At runtime ▪ One of several graph drivers ▪ These are NOT persistent ▪ Persistent storage ▪ Volumes attached to containers for persistent data ▪ Most of this talk will focus on this type of storage
    [Show full text]
  • Sibylfs: Formal Specification and Oracle-Based Testing for POSIX and Real-World File Systems
    SibylFS: formal specification and oracle-based testing for POSIX and real-world file systems Tom Ridge1 David Sheets2 Thomas Tuerk3 Andrea Giugliano1 Anil Madhavapeddy2 Peter Sewell2 1University of Leicester 2University of Cambridge 3FireEye http://sibylfs.io/ Abstract 1. Introduction Systems depend critically on the behaviour of file systems, Problem File systems, in common with several other key but that behaviour differs in many details, both between systems components, have some well-known but challeng- implementations and between each implementation and the ing properties: POSIX (and other) prose specifications. Building robust and portable software requires understanding these details and differences, but there is currently no good way to system- • they provide behaviourally complex abstractions; atically describe, investigate, or test file system behaviour • there are many important file system implementations, across this complex multi-platform interface. each with its own internal complexities; In this paper we show how to characterise the envelope • different file systems, while broadly similar, nevertheless of allowed behaviour of file systems in a form that enables behave quite differently in some cases; and practical and highly discriminating testing. We give a math- • other system software and applications often must be ematically rigorous model of file system behaviour, SibylFS, written to be portable between file systems, and file sys- that specifies the range of allowed behaviours of a file sys- tems themselves are sometimes ported from one OS to tem for any sequence of the system calls within our scope, another, or written to support application portability. and that can be used as a test oracle to decide whether an ob- served trace is allowed by the model, both for validating the File system behaviour, and especially these variations in be- model and for testing file systems against it.
    [Show full text]
  • A NAS Integrated File System for On-Site Iot Data Storage
    A NAS Integrated File System for On-site IoT Data Storage Yuki Okamoto1 Kenichi Arai2 Toru Kobayashi2 Takuya Fujihashi1 Takashi Watanabe1 Shunsuke Saruwatari1 1Graduate School of Information Science and Technology, Osaka University, Japan 2Graduate School of Engineering, Nagasaki University, Japan Abstract—In the case of IoT data acquisition, long-term storage SDFS, multiple NAS can be handled as one file system and of large amounts of sensor data is a significant challenge. When a users can easily add new NAS. cloud service is used, fixed costs such as a communication line for The remainder of this paper is organized as follows. In uploading and a monthly fee are unavoidable. In addition, the use of large-capacity storage servers incurs high initial installation section 2, we discuss the issues associated with the sensor data costs. In this paper, we propose a Network Attached Storage storage. Section 3 describes the overview and implementation (NAS) integrated file system called the “Sensor Data File System of the proposed file system, SDFS. In section 4, we evaluate (SDFS)”, which has advantages of being on-site, low-cost, and the performance of SDFS and existing file systems. Section 5 highly scalable. We developed the SDFS using FUSE, which introduces related work, and Section 6 summarizes the main is an interface for implementing file systems in user-space. In this work, we compared SDFS with existing integrated storage findings of this paper. modalities such as aufs and unionfs-fuse. The results indicate that II. ISSUES ASSOCIATED WITH THE SENSOR DATA STORAGE SDFS achieves an equivalent throughput compared with existing file systems in terms of read/write performance.
    [Show full text]