System Compleat.

'swift'에 해당되는 글 3건

  1. Openstack Swift with keystone on multiple nodes. 1
  2. Rackspace published Openstack reference site
  3. sg3_utils 3

Openstack Swift with keystone on multiple nodes.

Techs


 

( Younjin.jeong@gmail.com, 정윤진)

 

 

I’ll try to explain with this post about how to make swift storage cluster works with keystone service. If you have been worked with this open-source based project, you might get struggled, or suffered to configure because there’re not many information about this brand-new cluster. It’s because not only less information, there’re so many old versions and instructions, which means there’re not many certified working set exists. The Launchpad site is some kind of chaos. If you goolge about it, there’re only questions without right answers, and closed issues without comments. One another cause is that this project is so young, and things get changed very fast. All of those reasons will make you get angry to use this, and you may throw your keyboards during setup this brand-new cluster. The hardest thing is that understanding about how the keystone works, and how it can be plugged into swift-proxy’s middle ware. I’ll do not explain about what the keystone is, and what is the swift is as well. I’ll try to give you the instructions what is the result of my research about it. I also made swift + swauth system before, but it’s not that hard, and the swauth is not welcome in nowadays.

 

One more thing to let you know is, this research is based on multi-node cluster use. All components are installed on physically different server, and it’s network is combined with Arista 10G network with iBGP and eBGP with Quagga. But network is not major issue on this post, so I’ll keep it for next time.


The storage cloud install on multiple nodes went like this. 


1. Install and connect every node physically. Power cord, TwinAx, UTP, etc.

2. Setup the server BIOS and IPMI. 

3. Configure all switches. 

4. Install Ubuntu 12.04 on management server. 

5. Write Chef code for automated install. 

6. Prepare all nodes with PXE boot and network install. 

7. Update each configurations to every node by using chef. 

8. Check its functionalities. 



Quanta servers


 

Working environment as follows :

 

1.    Keystone server which is running with 192.168.1.200

2.    Swift proxy server running with 192.168.1.2/24 for admin, and it has 10G interface for services. I made a simple rule about network expansion, so the 10G network has similar IP structure, such as 10.0.1.2/24. And it also have ipmi network for physical control, such as boot order, power managements, its IP is 192.168.1.102. Every cabinet is designed to use /24 network.

3.    Swift storage servers running with 192.168.1.3 – 10 , also has 10G for 10.0.1.3 – 10.0.1.10

4.    Swift version is 1.6.1, you can get it from openstack github.

5.    Keystone is also available on openstack github.

6.    Each storage server has 12 disks for store, and 2 ssd disks for OS.

7.    Ubuntu version is 12.04 LTS.

8.    Quanta servers were used. ( X22-RQ, X12 series )

9.    Arista 7124SX per cabinet.

10. Cisco 2960 per cabinet.



Bluesnap-XP, RS-232 to Bluetooth

 



Every servers ( a.k.a bare-metals )  are installed by automation tool, chef and pxe boot. I’ve downloaded all packages from github.com, and you can also find the url easily.  To install swift successfully, there’re some python modules are needed. If there are no modules exists, then the python will show you error message and you’ll be get which python modules is needed easily. If you don’t know the exact name of the package, then you can search it by typing “apt-get update ; apt-cache search <string>”.

 

I have installed additional python modules packages as below.

 

 

root@allnew-quanta:/root# apt-get install python-eventlet python-netifaces \ 
python-pastedeploy python-webob openssl libssl-dev \
python-setuptools python-lxml python-libxslt1 python-dev

 

After install the swift, you’ll need to configure storage server, such as xfs file system, mount all of it, and build rings.  This configurations are well documented in swift multiple-node install, so I’ll not describe about it. More important thing is, setup the swift proxy server. As you may know, the proxy server should have keystone middle ware on it. So, you need to install keystone with swift on proxy server.  It also can be easily done with python setup.py install. After install it, you need to setup the proxy-server.conf. Here’s the recommended ( I mean the basic ) configuration for it.

 

[DEFAULT]
cert_file = /etc/swift/cert.crt
key_file = /etc/swift/cert.key
bind_port = 8080
user = swift
log_facility = LOG_LOCAL1
workers = 5

[pipeline:main]
pipeline = catch_errors healthcheck cache authtoken keystone proxy-server

[app:proxy-server]
use = egg:swift#proxy
account_autocreate = true

[filter:keystone]
paste.filter_factory = keystone.middleware.swift_auth:filter_factory
operator_roles = admin, swiftoperator

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory

# Delaying the auth decision is required to support token-less
# usage for anonymous referrers ('.r:*') or for tempurl/formpost
# middleware.

delay_auth_decision = 0

auth_port = 35357
auth_protocol = http
auth_host = 192.168.1.200
auth_token = ADMIN
admin_token = ADMIN

[filter:cache]
use = egg:swift#memcache
set log_name = cache

[filter:catch_errors]
use = egg:swift#catch_errors

[filter:healthcheck]
use = egg:swift#healthcheck



 

You may install additional python module needed to run swift proxy. It’s same story. Install the additional packages by referencing error messages.

 

After finish swift cluster, you’ll need to configure keystone server. You may consider high-availability for keystone service. Keystone can be sit on sqlite and mysql both, so you can find some way from goole search.

 

Here’s the keystone.conf configuration which is running with database. As you may know, there’s a way to use static file to setup, but if you want to use a feature, such like sharing, then you’ll need database to manage keystone.

 

[DEFAULT]
# A "shared secret" between keystone and other openstack services
admin_token = ADMIN

# The IP address of the network interface to listen on
bind_host = 0.0.0.0

# The port number which the public service listens on
public_port = 5000

# The port number which the public admin listens on
admin_port = 35357

# The port number which the OpenStack Compute service listens on
# compute_port = 8774

# === Logging Options ===
# Print debugging output
verbose = True

# Print more verbose output
# (includes plaintext request logging, potentially including passwords)
debug = True

# Name of log file to output to. If not set, logging will go to stdout.
log_file = keystone.log

# The directory to keep log files in (will be prepended to --logfile)
log_dir = /var/log/keystone

# Use syslog for logging.
# use_syslog = False

# syslog facility to receive log lines
# syslog_log_facility = LOG_USER

# If this option is specified, the logging configuration file specified is
# used and overrides any other logging options specified. Please see the
# Python logging module documentation for details on logging configuration
# files.
# log_config = logging.conf

# A logging.Formatter log message format string which may use any of the
# available logging.LogRecord attributes.
#log_format = %(asctime)s %(levelname)8s [%(name)s] %(message)s

# Format string for %(asctime)s in log records.
log_date_format = %Y-%m-%d %H:%M:%S

# onready allows you to send a notification when the process is ready to serve
# For example, to have it notify using systemd, one could set shell command:
# onready = systemd-notify --ready
# or a module with notify() method:
onready = keystone.common.systemd

[sql]
# The SQLAlchemy connection string used to connect to the database
#connection = sqlite:////var/lib/keystone/keystone.db
connection = mysql://keystone:XXXXX@localhost/keystone
# the timeout before idle sql connections are reaped
# idle_timeout = 200

[identity]
driver = keystone.identity.backends.sql.Identity

[catalog]
# dynamic, sql-based backend (supports API/CLI-based management commands)
driver = keystone.catalog.backends.sql.Catalog

# static, file-based backend (does *NOT* support any management commands)
#driver = keystone.catalog.backends.templated.TemplatedCatalog

template_file = /etc/keystone/default_catalog.templates 

[token]
driver = keystone.token.backends.kvs.Token

# Amount of time a token should remain valid (in seconds)
expiration = 86400

[policy]
driver = keystone.policy.backends.rules.Policy

[ec2]
# driver = keystone.contrib.ec2.backends.kvs.Ec2

[ssl]
#enable = True
#certfile = /etc/keystone/ssl/certs/keystone.pem
#certfile = /etc/keystone/cert.crt
#keyfile = /etc/keystone/ssl/private/keystonekey.pem
#keyfile = /etc/keystone/cert.key
#ca_certs = /etc/keystone/ssl/certs/ca.pem
#cert_required = True

[signing]
certfile = /etc/keystone/ssl/certs/signing_cert.pem
keyfile = /etc/keystone/ssl/private/signing_key.pem
#ca_certs = /etc/keystone/ssl/certs/ca.pem
#key_size = 1024
#valid_days = 3650
#ca_password = None

[ldap]
# url = ldap://localhost
# user = dc=Manager,dc=example,dc=com
# password = None
# suffix = cn=example,cn=com
# use_dumb_member = False

# user_tree_dn = ou=Users,dc=example,dc=com
# user_objectclass = inetOrgPerson
# user_id_attribute = cn
# user_name_attribute = sn

# tenant_tree_dn = ou=Groups,dc=example,dc=com
# tenant_objectclass = groupOfNames
# tenant_id_attribute = cn
# tenant_member_attribute = member
# tenant_name_attribute = ou

# role_tree_dn = ou=Roles,dc=example,dc=com
# role_objectclass = organizationalRole
# role_id_attribute = cn
# role_member_attribute = roleOccupant

[filter:debug]
paste.filter_factory = keystone.common.wsgi:Debug.factory

[filter:token_auth]
paste.filter_factory = keystone.middleware:TokenAuthMiddleware.factory

[filter:admin_token_auth]
paste.filter_factory = keystone.middleware:AdminTokenAuthMiddleware.factory

[filter:xml_body]
paste.filter_factory = keystone.middleware:XmlBodyMiddleware.factory

[filter:json_body]
paste.filter_factory = keystone.middleware:JsonBodyMiddleware.factory

[filter:user_crud_extension]
paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory

[filter:crud_extension]
paste.filter_factory = keystone.contrib.admin_crud:CrudExtension.factory

[filter:ec2_extension]
paste.filter_factory = keystone.contrib.ec2:Ec2Extension.factory

[filter:s3_extension]
paste.filter_factory = keystone.contrib.s3:S3Extension.factory

[filter:url_normalize]
paste.filter_factory = keystone.middleware:NormalizingFilter.factory

[filter:stats_monitoring]
paste.filter_factory = keystone.contrib.stats:StatsMiddleware.factory

[filter:stats_reporting]
paste.filter_factory = keystone.contrib.stats:StatsExtension.factory

[app:public_service]
paste.app_factory = keystone.service:public_app_factory

[app:admin_service]
paste.app_factory = keystone.service:admin_app_factory

[pipeline:public_api]
pipeline = stats_monitoring url_normalize token_auth admin_token_auth xml_body json_body debug ec2_extension user_crud_extension public_service

[pipeline:admin_api]
pipeline = stats_monitoring url_normalize token_auth admin_token_auth xml_body json_body debug stats_reporting ec2_extension s3_extension crud_extension admin_service

[app:public_version_service]
paste.app_factory = keystone.service:public_version_app_factory

[app:admin_version_service]
paste.app_factory = keystone.service:admin_version_app_factory

[pipeline:public_version_api]
pipeline = stats_monitoring url_normalize xml_body public_version_service

[pipeline:admin_version_api]
pipeline = stats_monitoring url_normalize xml_body admin_version_service

[composite:main]
use = egg:Paste#urlmap
/v2.0 = public_api
/ = public_version_api

[composite:admin]
use = egg:Paste#urlmap
/v2.0 = admin_api
/ = admin_version_api

 

 

Now, you can start keystone service by using keystone-all. If you need service management for keystone, then you can make some script for chkconfig.  There are good documents already exists.

 

Oh, before you start your keystone service with mysql, you need to configure mysql service. Create database and user, then give some proper privileges to it. You can see the database connection string in above configuration.

 

Before you setup the keystone, you may need to understand about how the tenant/user/role/key work with account/user/key in swift. If you already experienced how to use swift api, then you know the credential goes like account:user and key pair. The tenant matches with account, and user is user.

 

Here’s the instructions about how to setup the keystone, and please remember that our proxy-server.conf has allowed the role “admin” and “swiftoperators”, and the keystone.conf has default admin key, which is “ADMIN”.

 

 

First of all, install the python-keystoneclient for your setup system. There’re no mac version. Install it on your keystone server. Openstack keystone package does not contain the “keystone” tool, so you’ll need it if you didn’t install keystone with apt-get.

 

a. Create a tenant.

 

root@allnew-quanta: ~# keystone --username admin --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 tenant-create --name=service 

 

Note that the “endpoint” assigned in command line. You can specify it as OS environment variable.

 

 

b. Then, create an user. Type “keystone –token ADMIN –endpint YOURENDPOINT tenant-list” to see the ID.

 

root@allnew-quanta: ~#  keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 user-create --name=swift --pass=swiftadmin --tenant_id=ID

 

 

c. Create services. Keystone is usually assigned as identity service, and Swift is object-store.

 

root@allnew-quanta: ~# keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 service-create --name=swift --type=object-store --description="Swift Service"

root@allnew-quanta: ~# keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 service-create --name=keystone --type=identity --description="Keystone Identity Service"

 

 

d. Attach the service with endpoint.

 

root@allnew-quanta: ~#  keystone --token ADMIN --endpoint http://172.17.17.76:35357/v2.0 endpoint-create --region RegionOne --service_id=SWIFT_SERVICE_GUID --publicurl 'https://192.168.1.2:8080/v1/AUTH_%(tenant_id)s' --adminurl 'https://192.168.1.2:8080/' --internalurl ' https://192.168.1.2:8080/v1/AUTH_%(tenant_id)s'

root@allnew-quanta: ~#  keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 endpoint-create --region RegionOne --service_id=KEYSTONE_SERVICE_GUID  --publicurl 'http://192.168.1.200:5000/v2.0' --adminurl 'http://192.168.1.200:35357/v2.0' --internalurl 'http://192.168.1.200:5000/v2.0'

 

 

e. Crete roles.

 

root@allnew-quanta: ~#  keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 role-create --name=admin 

root@allnew-quanta: ~#  keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 role-create --name=swiftoperator

 

 

 

f. Attach users to a role.

 

root@allnew-quanta: ~#  keystone --token ADMIN --endpoint http://192.168.1.200:35357/v2.0 user-role-add --tenant_id=TENANT_ID --user=USER_ID --role=ROLE_ID

 

 

 

With swift tool  ( the swift python client tool ), you can check it’s work or not. If it works fine, then you can see the results as below.

 

root@allnew-quanta:/etc/keystone# swift -V 2 -A http://192.168.1.200:35357/v2.0 -U service:swift -K swiftadmin stat

Account: AUTH_6049fcdd4c3a46909a9dbaad04f1636a

Containers: 0 Objects: 0 Bytes: 0 Accept-Ranges: bytes X-Timestamp: 1345122033.16266 X-Trans-Id: tx166227c25e604e4db4c5bdc9039041a4

 

This means, now you can do CRUD to swift storage cluster with swift tool.

 

root@allnew-quanta: ~#  swift -V 2 -A http://192.168.1.200:35357/v2.0 -U service:swift -K swiftadmin upload test keystone.conf
keystone.conf

root@allnew-quanta: ~# swift -V 2 -A http://192.168.1.200:35357/v2.0 -U service:swift -K swiftadmin list
test

 

Basically, the keystone controls authentications for users. More than that, it can be used to control container sharing by using tenants. Currently, I’m focusing on how to implement it as an enterprise service and how it can be installed with Chef. So, will not explain about it more.

 

As I mentioned at top of this post, install swift and keystone on multiple nodes is not simple work for now. I have no doubt that there will be good methods to install this clusters will come out later by many contributors. But for now, well until now, it was not an easy work to do. And its why I wrote this post at this moment.

 

If you’re a web developer, you may interested in how to implement it with Keystone and Swift API for your applications. There’s good explains about how to do this with curl. To understand its action more, then visit this blog.

 

http://blog.chmouel.com/2011/11/24/swift-and-keystone-middleware-part1/

 

Since the cluster works, you can test many things about to running cloud storage and S3 like infrastructure. And that’s exactly what I’m working for.

 

Hope you’ll have successfully working set of private storage cloud on your own.

 


( Younjin.jeong@gmail.com, 정윤진

Rackspace published Openstack reference site

Techs
( younjin.jeong@gmail.com, 정윤진 )


AWS와 함께 클라우드 서비스의 강력한 주자인 Rackspace 가 Openstack 을 사용한 클라우드 구현에 있어 필요한 내용들을 간단하게 정리한 레퍼런스 사이트를 오픈했다. 

http://www.referencearchitecture.org

이 블로그에서는 그동안 OpenStack 에 대한 내용은 한번도 언급하지는 않았지만, 모 기업에서 현재 서비스 중인 스토리지 클라우드
 구현에 참여한 적이 있어 익히 알고 있다. 참여 하였다고는 해도 실제 코드를 반영하거나 했던 부분은 없으며, 주로 인프라 관련 문제의 트러블 슈팅에 참여 했었기에 전반적인 아키텍처라던가 구현의 방법, 자주 발생하는 문제는 어떠한 것들이 있는지에 대해 나름대로 경험을 가지고 있다고 생각한다. 

위의 사이트는 Rackspace가 겪었던 모든 경험을 말해주지는 않는다. 나 역시 주로 기업과의 계약관계에서 일을 하기 때문에 무엇이 어떻다 하고 말하기가 곤란한 경우가 더러 있다. 따라서 가장 중요한 것은 경험해 보는 것이며, 오픈스택이 다른 도구들에 비해 어떠한 장점과 단점을 가지고 있는지, 그리고 단점은 어떻게 다른 솔루션들을 통해 극복 해 낼 수 있는지에 대해서는 구현하고자 하는 서비스의 Use Case 에 따른 충실한 테스트와 튜닝이 함께 고려되어야 할 것이다. 

오픈 스택은 Rackspace 와 NASA 가 공동으로 참여하고 있는 오픈소스 프로젝트이며, 이는 크게 Nova 라 불리우는 컴퓨팅 클라우드의 구현 도구와 Swift 라 불리우는 오브젝트 스토리지, 그리고 Glance 라 불리는 이미지 서비스로 구성되어 있다. 이미지 서비스는 사진과 같은 이미지가 아니라, 클라우드에서 사용되는 VM 의 원본 템플릿을 지칭하는 말이다. 

클라우드에 관심이 있으신 분들이라면 이 오픈 스택에 대해 한번쯤은 들어 보았을 것이며, 이와 비슷한 도구들에도 경험이 있으리라 생각한다. 하지만 이 오픈 스택의 경우 인터넷을 통한 자료를 찾아 내는 것이 보통 어려운 일이 아닐 것이다. Zone 이 무엇인지, Multi-Node 클러스터는 어떻게 만들어야 하는지에 대한 위키페이지는 제공이 되고 있지만, 실제 이 Zone 을 몇개로 구성해야 하는지, 하드웨어 스펙은 어떻게 잡아야 하는 지에 대한 내용들은 찾아 내기가 쉽지 않을 것이다.

위의 사이트는 그러한 부분들에 대한 욕구를 일정 부분 충족 시켜 줄 것이며, 만약 Private 클라우드를 구현 하고자 한다면 도움이 될 수 있다. 다만, 여러분은 이 레퍼런스 페이지와 오픈 스택 사이트의 위키를 참조하더라도, 프로덕션 레벨의 서비스 구현에 있어서는 매우 큰 난관을 겪을 수도 있다. 이는 여러가지의 설정값이나 아키텍처의 선정에 있어서 고려해야 하는 부분이 매우 많으며, Python 으로 개발된 도구이기에 가지는 한계도 일부 발생 할 수 있다. 더군다나 운영의 측면에 있어서도 리눅스에 익숙하지 않다면 고난을 겪을 가능성이 다분히 있다.

오픈 스택 프로젝트는 델에서 지원하고 있다. 이는 Rackspace 와 Dell 이 매우 긴밀한 관계이기 때문인 것으로 보여지는데, 이러한 이유에서인지 델에서는 Crowbar 라 불리는 오픈스택 설치 도구를 최근에 배포하였다. 

http://content.dell.com/us/en/enterprise/by-need-it-productivity-data-center-change-response-openstack-cloud

이는 PXE 부팅과 Chef 를 통한 자동화된 도구이다. 따라서 간단하게 사용하기에는 나쁘지 않을 것으로 생각된다. 사용 방법이나 대해서는 위의 페이지를 참고하며, 개념에 대해서는 다음의 링크를 살펴보는 것도 좋다. 

http://robhirschfeld.com/2011/03/14/how-openstack-installer-works/

나는 지금 국내의 모 기업을 위한 클라우드 프로젝트에서 동일한 부분을 처리하는 코드를 만들고 있다. 이는 Crowbar 와 유사한 형태의 도구이지만, 보다 고객사에 최적화 되어 있다고 생각한다.

사실 델은 다른 HP 나 IBM 보다는 이런 부분에서 보다 빨리 움직이고 있는 듯 하다. DevOps 라 불리우는 사람들이 클라우드 인프라 개발에 있어 매우 중요한 역할을 하지만, 전 세계에서 오픈스택을 통해, 아니 클라우드 인프라 개발을 경험한 사람들은 극소수이다. 
이는 전 세계를 통틀어도 3백명 이하의 인원들 뿐일 것이며, 따라서 클라우드를 구현하고자 하는 기업들에게 저러한 도구의 지원은 좋은 시작점이 될 수 있다. 물론 저러한 도구를 상용 서비스에서 직접 사용하는 것은 사용자의 판단에 달려있다는 말을 빼 놓으면 안될 것 같다. 

델이나 HP, IBM 하드웨어를 보면 전부 OEM 투성이다. 거기에 각 기업들의 관리 소프트웨어 또는 하드웨어와 서포트를 함께 파는 형국인데, 클라우드에 있어서 특히 저렴한 가격 경쟁력을 가지려는 클라우드 구현에 있어서는 저러한 하드웨어로는 비용이 높아 질 수 밖에 없다. 우분투를 쓰는것이 가장 좋은 시절이 올 줄은 몰랐지만, 아무튼 "우리는 우분투 따위의 리눅스는 지원하지 않습니다" 하는 벤더를 선정하게 되면 골치가 아플 것이다. 가장 범용적으로 많이 사용되고, 가장 많은 사용자들이 선택하는 하드웨어를 선정하는 것, 여기에 약간의 벤더를 지원하는 하드웨어라면 대다수의 기업에서도 만족하지 않을까 생각한다. 저렴하고, 지원되고, 델과 IBM, HP 에 팔리는 서버의 원형을 만드는 회사의 제품이라면 말이다. 


아무튼. 위의 내용들은 클라우드 구현에 관심이 있다면 한번 쯤 살펴보는 것이 남는 것이라 생각한다. 


( younjin.jeong@gmail.com, 정윤진 ) 

 

sg3_utils

Techs
(younjin.jeong@gmail.com, 정윤진)


절대로_찾을수_없을걸_JPG

Image from : https://supcom.hgc.jp/english/img/supcom/DiskArray.jpg

 
이런 저런 용도로 JBOD이 리눅스에서 굉장히 많이 사용되고 있다. 뭐 물론 계속 사용 해 왔던 분들에게는 별 문제는 아니지만, 이제 막 이런 장비를 사용하여 Swift 등을 구현하다 보면 아주 간단한 장애 디스크 하나 찾는게 골치 아파질 때가 있다.  물론 디스크 하나 찾기위해 이 도구가 필요 한 것은 아니지만, 이러한 도구 없이 X Window의 힘을 빌리기란 시스템 하는 분들 입장에서는 여간 챙피한 일이 아닐 것이다. 아, 물론 그렇게 느끼시지 않는다면 관계 없다.  살포시 디스크 매니저를 찾아 보자. 

제목에서와 같이, 이 오랜만의 포스팅은 sg3_utils 에 대한 내용을 설명한다. 아 물론, 친절하게 뭐가 뭐다 하고 설명하면 더 좋겠지만, 나는 여기서 더 친절하게 무려 sg3_utils 홈 페이지의 내용 중 가장 쓸만 하다 싶은 내용을 아예 번역을 해 버렸다. 물론 번역이 그다지 나이스한 품질은 아니지만, 일하다가 짬짬히 되는대로 써 놓은 것이기 때문에, 또 별도의 다른 번역 문서도 아직 존재하지 않는 듯 하기에 포스팅을 해 본다. 

아 물론, 각 표에 있는 내용까지 번역을 했더라면 좋았겠지만, 그닥 시간이 허용하지 않아서... 한시간 동안 완전 날림 번역이지만 그래도 영어로는 죽어도 못 보겠다 하시는 분들만 보시면 된다. 

sg3_utils 패키지는, 리눅스에서 디스크 관련 Low Level 작업을 할 때 꽤나 유용한 패키지다. 디스크가 두세개 정도 밖에 없다면 대략 무슨 디스크가 뭔 디스크인지 쉽게 알 테지만, 24개 48개 96개 이렇게 되어버리는 데다가 별도의 RAID 구성마저 하지 않는다면 골치가 아파질 것이다. 

RAID도 없이 그렇게 무식하게 디스크를 쓰는데가 어디 있냐고 물으신다면 Swift 라 답하겠어효... 

클라우드의 싸게 넣어서 준비시키고 쓰다가 쫑나면 교체해 버리고의 컨셉은 디스크 사용에도 적용되기 시작했다. 이는 바로 Swift 가 제공하는 '오브젝트 스토리지'라는 신개념 스토리지 (라고 쓰고 그냥 웹 파일 서비스 라고 읽는다) 에서는, 디스크에 별도의 볼륨 구성 없이 각 디스크를 생짜로 그냥 사용한다. 대부분의 시스템 관리자 분들 께서는 Writeback이니, ZFS의 log이니, RAID Level 이 어쩌고 저쩌고에 능통하시겠지만, 이 단순한 디스크+웹 서비스는 그 간단한 구성 만큼이나 디스크 구성도 간단하게 처리해 버린다. 

따라서 별로 되게 어려울 것은 없지만, 리눅스 그 자체의 안정성이 쵸큼 중요하게 되는 것도 이 서비스라고 할 수 있겠다. Commodity Hardware 에서 어떠한 방법으로 안정성을 구가하는가가 오히려 더 중요한 포인트가 될 수도 있음이다. 

아 물론, 우분투 LTS 버전이 무조건 안정적이다 하시는 분들도 계시고, 여기서 커널 바꾸면 세상 무너지는 줄 아는 분들도 계시긴 하지만, 그런 분들에게 이러한 Low Level 도구는 위험하므로 얼른 다른자료 찾아 보시길 권고한다. 물론, 그까이꺼 LED 따위 고장나면 바로 켜져야 하는거 아냐 하고 생각 하시는 분들 께서도 굳이 이런 난잡한 번역 읽느라 고생 하실 필요가 없음.

자꾸 새는데, 뭐 결국은 sg3_utils 로 해 볼 수  있는 것들이 많고, 보통 Production 단계 이전의 Dev나 STAG 환경에서 마음껏 가지고 놀아보는게 중요하겠다. 

각설하고, 웹 버전으로 보고 싶으신 분들은 아래의 펼쳐보기를 누르시면 된다. 
원래의 작업을 워드로 처음 해 봤더니, pdf 로 만들 수도 있어서 한번 만들어 봤다. 
번역이 좀 구려도 대충 보시라. 

 


Swift 에 대해서는 시간이 나면 따로 포스팅을.. 


(younjin.jeong@gmail.com, 정윤진)