Upload
chih-chieh-huang
View
554
Download
4
Embed Size (px)
DESCRIPTION
Citation preview
When IaaS Meets DFS
IaaS平台中儲存元件的考量與其需求
Huang Chih-Chieh (soem) @ NEET
2
Outline
• What is IaaS• What is OpenStack• Storage Types in IaaS• Ceph– Issues
• Summary
3
WHAT IS IAAS
4
Cloud Service Models Overview
• What if you want to have an IT department ?– Similar to build a new house in previous analogy
• You can rent some virtualized infrastructure and build up your own IT system among those resources, which may be fully controlled.
• Technical speaking, use the Infrastructure as a Service (IaaS) solution.
– Similar to buy an empty house in previous analogy• You can directly develop your IT system through one cloud platform,
and do not care about any lower level resource management.• Technical speaking, use the Platform as a Service (PaaS) solution.
– Similar to live in a hotel in previous analogy• You can directly use some existed IT system solutions, which were
provided by some cloud application service provider, without knowing any detail technique about how these service was achieved.
• Technical speaking, use the Software as a Service (SaaS) solution.
5
From IaaS to PaaS
Traditional IT
Networking
Storage
Servers
Virtualization
OS
Middleware
Runtime
Data
Applications
You
Man
age
IaaS
Networking
Storage
Servers
Virtualization
OS
Middleware
Runtime
Data
Applications
You
Man
age
Provider Manage
PaaS
Networking
Storage
Servers
Virtualization
OS
Middleware
Runtime
Data
Applications
You
Man
age
Provider Manage
6
Service Model Overview
7
WHAT IS OPENSTACK
8
9
10
OpenStack Storage
cinder-volume
11
STORAGE TYPES IN IAAS
12
OpenStack Storage
• Instance Storage Provider– Off Compute Node Storage• Shared File System
– On Compute Node Storage• Shared File System
– On Compute Node Storage• Non-shared File System
• Image Repository– Glance
13
OpenNebula Storage
14
• Properties– File System vs. Block Device– Shared vs. Non-shared
• Four types:– Shared File System– Non-Shared File System– Shared Block Device– Non-Shared Block Device
SSCloud Storage
15
• File System– Bootable image / Small image• Small image
– FS cache in host memory– Random accessing
– Type• Shared
– DFS (ceph), NFS (nfsd)
• Non-Shared– Local filesystem + scp
SSCloud Storage
16
• Block device (with LVM)– Additional space / large image– Heavy accessing image
• Large image– No FS cache in host memory => save memory– Large chunk access
» Hadoop (64MB~128MB per file)
– Type• Shared
– iSCSI + LVM
• Non-Shared– LVM
SSCloud Storage
17
Storage Systems
• File Based– NFS– DFS• Lustre• GlusterFS• MooseFS• Ceph
18
Storage Systems
• Block Based– iSCSI + LVM– DRBD– VastSky– KPS: Kernel-based Programmable Storage System– Ceph
19
Storage Systems
• Object Based– Openstack Swift– Hadoop HDFS• with WebHDFS (1.0.4-stable) or HTTPFS (2.0.3-alpha)
– Ceph
20
CEPHCEPH: THE FUTURE OF STORAGE™
21
Ceph
• Overview– Ceph is a free software distributed file system.– Ceph's main goals are to be POSIX-compatible, and
completely distributed without a single point of failure.– The data is seamlessly replicated, making it fault tolerant.
• Release– On July 3, 2012, the Ceph development team released
Argonaut, the first release of Ceph with long-term support.
22
Ceph
• Introduction– Ceph is a distributed file system that provides
excellent performance ,reliability and scalability.– Objected-based Storage.– Ceph separates data and metadata operations by
eliminating file allocation tables and replacing them with generating functions.
– Ceph utilizes a highly adaptive distributed metadata cluster, improving scalability.
– Using OSD to directly access data, high performance.
23
Ceph
•Objected-based Storage
24
Ceph
• Goal– Scalability• Storage capacity, throughput, client performance.
Emphasis on HPC.
– Reliability• Failures are the norm rather than the exception, so the
system must have fault detection and recovery mechanism.
– Performance• Dynamic workloads Load balance.
25
Ceph
• Ceph Filesystem– POSIX• File based
• Ceph Block Device– RBD• Block based
• Ceph Object Gateway– Swift / S3 Restful API• Object based
26
Ceph
• Three main components– Clients : Near-POSIX file system interface.– Cluster of OSDs : Store all data and metadata.– Metadata Cluster : Manage namespace(file
name)
27
Three Fundamental Design
1. Separating Data and Metadata– Separation of file metadata management from the
storage.– Metadata operations are collectively managed by
a metadata server cluster.– User can direct access OSDs to get data by
metadata.– Ceph remove data allocation lists entirely.– Using CRUSH assigns objects to storage devices.
28
Separating Data and Metadata
• Ceph separates data and metadata operations
29
Separating Data and Metadata• Data Distribution with CRUSH– In order to avoid imbalance(OSD idle, empty) or
load asymmetries(hot data on new device). →distributing new data randomly.
– Ceph maps ojects into Placement groups(PGs)PGs are assigned to OSDs by CRUSH.
30
Dynamic Distributed Metadata Management
2.Dynamic Distributed Metadata Management Ceph utilizes a metadata cluster architecture based on Dynamic
Subtree Partitioning.(workload balance)
– Dynamic Subtree Partitioning• Most FS, use static subtree partitioning
→imbalance workloads and easy hash function.• Ceph’s MDS cluster is based on a dynamic subtree
partitioning. →balance workloads
31
Reliable Distributed Object Storage
3.Reliable Autonomic Distributed Object Storage– Replica.– Failure Detection and Recovery.
32
Client
• Client Operation– File I/O and Capabilities
Request
Client(open file)
MDS
Translate file name into
inode(inode number, file
owner, mode, size, …)Check OK, return
Return inode number, map file data into objects(CRUSH)
OSD
Direct access
33
Client
• Client Synchronization– If Multiple clients(readers and writers) use same
file, cancel any previously read and write capability until OSD check OK.• Traditional: Update serialization. →Bad performance• Ceph: Use HPC(high-performance computing
community) can read and write different parts of same file(diff bojects).→increase performance
34
Metadata
• Dynamically Distributed Metadata– MDSs use journaling• Repetitive metadata updates handled in memory.• Optimizes on-disk layout for read access.
– Per-MDS has journal, when MDS failure another node can quickly recover with journal.
– Inodes are embedded directly within directories.– Each directory’s content is written to the OSD
cluster using the same striping and distribution strategy as metadata journals and file data.
35
Replica
• Replication– Data is replicated in terms of PGs.– Clients send all writes to the first non-failed OSD in
an object’s PG (the primary), which assigns a new version number for the object and PG and forwards the write to any additional replica OSDs.
36
Failure detection
• Failure detection– When OSD not response → sign “down”– Pass to the next OSD.– If first OSD doesn’t recover →sign “out”– Another OSD join.
37
Failure Recovery
• Recovery and Cluster Updates– If an OSD1 crashes → sign “down”– The OSD2 take over as primary.– If OSD1 recovers → sign “up”– The OSD2 receives update request, sent new
version data to OSD1.
38
EVERYTHING LOOKS GOOD, BUT…
39
Issues
• Highly developed– 0.48• Monitor waste CPUs• Recovery into un-consistency state
– 0.56• Bugs in file extend behavior
– Qcow2 images have got IO errors in VMs kernel, » but things are going well in the log of Ceph.
– 0.67• ceph-deploy
40
Issues
• Correct the time– 0.56• OSDs waste CPUs
– ntpdate tock.stdtime.gov.tw
– 0.67• health HEALTH_WARN clock skew detected on mon.1
– ntpdate tock.stdtime.gov.tw– ntpserver
41
Issues
• CephFS is not statble– Newly system can use ceph RBD– Traditional system could only use the POSIX
interface• 0.56
– Ceph’s operation in a folder would be frozen,» if that folder is getting heavy loading.
– Bugs in file extend behavior
REF: http://www.sebastien-han.fr/blog/2013/06/24/what-i-think-about-cephfs-in-openstack/
42
Issues
• Mount ceph with– Kernel module• mount –t ceph …
– FUSE• ceph-fuse -c /etc/ceph/ceph.conf …
43
Issuesroot@SSCloud-01:/# cephfs /mnt/dev set_layout -p 5Segmentation fault
cephfs is not a super-friendly tool right now — sorry! :(I believe you will find it works correctly if you specify all the layout parameters, not just one of them.
root@SSCloud-01:/# cephfs -hnot enough parameters!usage: cephfs path command [options]*Commands: show_layout -- view the layout information on a file or dir set_layout -- set the layout on an empty file, or the default layout on a directory show_location -- view the location information on a file map -- display file objects, pgs, osdsOptions: Useful for setting layouts: --stripe_unit, -u: set the size of each stripe --stripe_count, -c: set the number of objects to stripe across --object_size, -s: set the size of the objects to stripe across --pool, -p: set the pool to use
Useful for getting location data: --offset, -l: the offset to retrieve location data for
root@SSCloud-01:/# cephfs /mnt/dev set_layout -u 4194304 -c 1 -s 4194304 -p 5root@SSCloud-01:/# cephfs /mnt/dev show_layoutlayout.data_pool: 5layout.object_size: 4194304layout.stripe_unit: 4194304layout.stripe_count: 1
44
SUMMARY
45
Summary
• There are three type of storage in IaaS– File-based, block-based, object-based
• Ceph is a good choice for IaaS– OpenStack store images in Ceph Block Device– Cinder or nova-volume to boot a VM• using a copy-on-write clone of an image
• CephFS is still highly developed– However, newer version is better.