Cisco UCS S3260 M5 디자인 매뉴얼 - 페이지 30

{카테고리_이름} Cisco UCS S3260 M5에 대한 디자인 매뉴얼을 온라인으로 검색하거나 PDF를 다운로드하세요. Cisco UCS S3260 M5 35 페이지. Server with cloudian hyperstore object storage

Design Criteria

JBOD versus RAID0 Disks

While Cloudian HyperStore as a SDS solution works with JBODs or with RAID0 disks, it is recommended to use

JBOD for the solution. The 12G SAS RAID controller in S3260 provides up to 4G of cache that can be used for

writes.

Memory sizing is based on the number of objects stored on each storage server, which is related to the average

file size and the data protection scheme. Standard designs call for 384GB for the S3260 M5 single node and

192GB for the S3260 M5 dual node configurations.

Cloudian Network requirements are standard Ethernet only. Please refer to the Network layout in Figure 9. While

Cloudian software can work on a single network interface, it is recommended to create different virtual interfaces

in Cisco UCS and segregate them. A client-access network and private-cluster network are required for the

operation. Cisco UCS S3260 has two physical ports of 40G each and the VIC allows you to create out many

Virtual interfaces on each physical port.

It is recommended to have a private-cluster network on one port and the client-access networks on another port.

This provides 40Gb bandwidth for each of these networks. While the client-access network requirements are

minimal, every storage node can take up to 40Gb of client bandwidth requirements. Also, by having the client and

cluster VIC's pinned to each fabric of the fabric interconnects, there is a minimal overhead of network traffic

passing through the upstream switches for inter-node communication, if any. This unique feature of fabric

interconnects and VIC's makes the design highly flexible and scalable.

The uplinks from fabric interconnects to upstream switches like Nexus, carry the traffic in case of FI failures or

reboots. A reboot for instance is needed during a firmware upgrade. While there is complete high availability built-

in the infrastructure, the performance may drop, depending on the uplink connectors from each FI to the Nexus

vPC pool. If you want 'no' or a 'minimal drop', increase the uplink connectors.

Similar to Amazon S3, the Cloudian HyperStore system supports the implementation of multiple "service regions."

Setting up the Cloudian HyperStore system to use multiple service regions is optional.

The main benefits of deploying multiple service regions are:



Each region has its own independent Cloudian HyperStore geo-cluster for S3 object storage.

Consequently, deploying multiple regions is another means of scaling-out your overall Cloudian HyperStore

service offering (beyond using multiple nodes and multiple datacenters to scale out a single geo-cluster). In

a multi-region deployment, different S3 datasets are stored in each region. Each region has its own token

space and there is no data replication across regions.



With a multi-region deployment, your service users can choose the service region in which their storage

buckets will be created. Users may choose to store their S3 objects in the region that's geographically

closest to them; or they may choose one region rather than another for reasons of regulatory compliance

or corporate policy.