Download - Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин
![Page 1: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/1.jpg)
Kirill Korotaev
VP of Advanced Research, Parallels
Система распределенного,
масштабируемого и высоконадежного
хранения данных для виртуальных
машин (и не только)HighLoad++, 22-23 октября 2012
![Page 2: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/2.jpg)
Prehistory
![Page 3: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/3.jpg)
Virtualization & needs
3
1. VM migration 2. HA on failures
![Page 4: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/4.jpg)
SAN storage
4
Redundancy
High availability
Monitoring
Self healing
Reliability
Fiber channel
Performance
![Page 5: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/5.jpg)
How to get best of 2
worlds?
5
local
SAN
100$ 100,000$
![Page 6: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/6.jpg)
Focus on needed capabilities is a key to success
Idea of maximum simplification
![Page 7: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/7.jpg)
From required capability to consistency
7
Consistency - “some well defined and understandable order” of operations.
Required for real file systems (NTFS, etx3/4,…) cause they use and rely on
these properties of real disks.
A AB B
Journal Metadata
• Immediate/Strict consistency
• Sequential consistency (all observers see the same order)
• Eventual consistency (no time guarantees, most object storages)
• Weak consistency (only synchronization primitives define order)
![Page 8: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/8.jpg)
We want grow on demand also…
• Grow on demand means ability to allocate more then locally
available (>HDD or no free space)
• Requires split of data into pieces
• Probability(any of N computer failure) is increasing with N
• So redundancy/replication and auto recovery is a MUST
• But recovery can be done in parallel (~1TB in 10mins)
• Good news is that MTTF ~1/T2, where T is recovery time.
• So let’s split all objects to chunks (64Mb)
• Replicate chunks, not objects
• Spread chunks over the cluster to reduce recovery T
• Need to take into account topology of cluster
8
![Page 9: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/9.jpg)
More ideas
9
Simplifications:
• No need for POSIX FS
• Optimize for big objects only
• Can assume infrequent/slow metadata updates
Major assumption:
• Shit happens: servers die, even DC can crash
![Page 10: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/10.jpg)
Why consistency is not easy? Replication…
10
Simplest case: object is fully stored on a single node
Next step: object is replicated, i.e. multiple instances present
Object
v1
v1
v1
v2
v2
v1 Stale data can be read!
Server2
Server3
t
Server1
DC
cra
sh
![Page 11: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/11.jpg)
c1v2
c2v2
Why consistency is not easy? Data striping…
11
Splitting data into chunks leads to similar issues as replication:
Server1
c1v1
File
c2v1
c1v1
c2v1
c1v2
c2v2
c1v1 c2v1
twrite
actual state is
c1v2+c2v2,
but all combinations
civj can be found
Note: c1v1 or/and c2v1 should never be read!
=
Server2
Server3 c1v1
Server4
Server5
Server6
c2v1
DC
cra
sh
write
![Page 12: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/12.jpg)
So why consistency is not easy?
12
Data versioning is crucial and should be attributed
to data, plus heavily checked on operations!
Problems with versions:
1. Tracking versions requires transactions support and sync operations.
SLOW!
2. Can’t store versions near data only! Node can not decide alone whether
it’s uptodate or not.
Solution:
1. Let’s update version only when some server can’t complete write! And
leave it constant on successful data modifications.
2. To solve #2 let’s store versions on metadata servers (MDS) – authority
which tracks full cluster state. It should be reliable and HA.
![Page 13: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/13.jpg)
Design
![Page 14: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/14.jpg)
Overall design
14
MDS
CS
Clients
…
…
Meta Data Server (MDS)
• Metadata database
• Chunks and versions tracker
• HA
Ethernet
CS CS CS CS CS CS
Chunk Server (CS)
• Stores data (chunks)
• Chunk management
• READ/WRITE
![Page 15: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/15.jpg)
Magic (MetaData) Server HA
• Single point of failure => need HA…
• Ouch, but we don’t want replicated DB, MySQL or Oracle…
It’s a nightmare to manage. Not scalable.
• Database adds noticeable latency per chunk access
15
We have to create our own replicated DB for MDS
![Page 16: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/16.jpg)
Local
journal
Meta Data Server database
16
Local
journal
Full state in memory
Ideas from GoogleFS:
• ~128 byte per chunk
• 64Mb RAM describe ~32 Terabytes
chunks
Commit deltas
• Journal stores modification records
• It’s growing, so need compacting
method
• To compact in background, need
memory snapshotting
• Journal and state can be synced to
outdated nodes
![Page 17: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/17.jpg)
Meta Data Server database compacting
17
Local
journal
Full state in memory
New
journal
Snap-
shot
New
journal
Snap-
shot
![Page 18: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/18.jpg)
PAXOS algorithm
The Part-Time Parliament, Leslie Lamport:
• The Island of Paxos, parliament government
• Legislators are traders, travel a lot and often not present in
chamber
• They used non-reliable messengers for notifications and
communication
• Decree is adopted using ballots, need majority of votes
• Legislators are each having it’s own journal of records
• Consistency of decrees is required
• Add/removal of legislators is needed
• Progress is needed
18
![Page 19: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/19.jpg)
Performance
![Page 20: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/20.jpg)
Chunk server performance tricks
20
Write requests are split (64k) and chained:
Chained write
Completion
CS CS CS
t
64k
1 server, 256K write3 servers, 256K split/chained write
3 servers, dumb
Write 256Kb req
![Page 21: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/21.jpg)
SSD caching on clients
• 3 parts: filter (RAM), cache, boot cache (1/8, 100MB / 2min)
• Sequential access detection relies on access time
• Write simply invalidates cached blocks
• Avoid interlaced reads: remote block, cached, remote,
cached
• Writes (caching) affect reads performance (user I/O)
21
{fileID, offset}
generation
blockid
accesstime…
8-way hash
and LRU
• SSD bursts performance > 10x times
• Caching on 2nd read access only to avoid excessive caching
• Detect sequential access and avoid caching
![Page 22: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/22.jpg)
SSD journaling at CS
• Bursts write performance, async commit to rotational drives
• Allows to implement data check summing and scrubbing
• Reason: major difference from object storages –
performance and latency are very noticeable and important.
Latency is not hidden by WAN.
22
![Page 23: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/23.jpg)
Summary
![Page 24: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/24.jpg)
Final result
Storage system:
• With file system interface, scalable to Petabytes
• Suitable for running VMs and Containers, Object Storage,
shared hosting and other needs
• SAN like performance over ethernet networks:
• 13K IOPS on 14 machines cluster (4 SATA HDD each)
• 600K IOPS with SSD caching
• 1TB drive recovery takes 10 minutes!
24
![Page 25: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/25.jpg)
Some experience to share
• Asynchronous non-blocking design
• QA: unit tests and stress testing are the must
• QA: how to emulate power off? SIGSTOP+SIGCONT/KILL.
• It hangs connections and avoids RESETs as if host
disappeared
• Drives/RAIDs/SSDs lie about FLUSHes.
• SSD write performance depends on data. Beware compression
inside.
• Checksum everything (4GB/sec) and validate HW memtest86
25
![Page 26: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/26.jpg)
Some experience to share
• All queues should be limited and controlled, like in TCP
congestion control is required (both for memory limit and latency
control, i.e. IO queue length)
• One client can fire Nx4K random requests and effectively it’s equivalent to
1MB requests. Congestion should be calculated correctly (taking into
accoung quality of queue).
• In addition to queues limit FDs/connections etc.
• Linux sync() / syncfs() is not usable
• Linux fdatasync() is 3.5-4x faster then fsync(), but should not be
used when file size changed.
• Replication should be done by pairs
26
![Page 27: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/27.jpg)
Some experience to share
• Cluster identity: unique ID and name
• Cluster resolving: DNS, manual and zeroconf
• Interesting OSDI’12 Microsoft Research storage: uniform network
topology, 2GB/sec per client, sorting world record 1.4TB in
~60sec.
27
![Page 28: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/28.jpg)
Object storage
28
Image: ext4 filesystem
Object Object Object
![Page 29: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/29.jpg)
Object storage
29
Image: ext4 filesystem
Object Object Object
![Page 30: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/30.jpg)
Object storage
30
Image: ext4 filesystem
Object O O
Image: ext4 filesystem
Object O O
Image: ext4 filesystem
Object O O
Image: ext4 filesystem
Object O O
Image: ext4 filesystem
Object O O
Image: ext4 filesystem
Object O O
![Page 31: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/31.jpg)
Thank You
31
Kirill Korotaev [email protected]
Try Parallels Cloud Server 6.0 beta2 at
http://www.parallels.com/product/pcs
![Page 32: Cистема распределенного, масштабируемого и высоконадежного хранения данных для виртуальных машин](https://reader033.vdocuments.mx/reader033/viewer/2022042715/5594ade61a28ab82408b45a5/html5/thumbnails/32.jpg)
Присоединяйся к лучшим! [email protected]
• Автоматизация оказания
облачных сервисов
• 10 млн. СМБ в 125 странах
• Виртуализация ПК и Mac
• 3 млн. ПК во всем мире
• 81% рынка в розничных сетях США
Parallels - лидер на международном рынке в своих сегментах
Работа в Parallels - от программирования в ядрах ОС до
создания web интерфейсов и мобильных приложений
• Интересные проекты
• Работа бок о бок с
легендами ИТ-
индустрии
• Процесс разработки
мирового класса
• Карьера, опционы
• 32