레이블이 IT인 게시물을 표시합니다. 모든 게시물 표시
레이블이 IT인 게시물을 표시합니다. 모든 게시물 표시

2019년 8월 22일 목요일

[IT] 스케일아웃 스케일 업

 어느 사이트나 서버를 운영하다보면 서버에 대한 성능에 대한 한계를 느끼는 경우가 생기게 된다. 예전 IT 운여환경에서는 서버를 교체하는 방식으로 기존 시스템의 성능을 향상 시키는 것이 일반 적이었다.  이러한 서버 성능향상 방법론은 이미 구시대의 유물이 되었다.

스케일 아웃 혹은 스케일 업을 통해 각 사이트에 사정에 맞게 서버 성능 향상에도 옵션이 있다.

1) 스케일 아웃

 ‘스케일 아웃’이란 서버를 여러 대 추가하여 시스템을 확장하는 방법이다. 예를 들어, ‘1’의 처리 능력을 가진 서버에 동일한 서버 4대를 더 추가하여, 총 ‘5’의 처리 능력을 만드는 것이다.

 서버가 여러 대가 되기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 ‘Load Balacing'이 필수적으로 동반되어야 한다. (소프트웨어적 요소가 필요함)


 스케일 아웃의 경우, 서버 한 대가 장애로 다운되더라도 다른 서버로 서비스 제공이 가능하다는 장점이 있고 HCI(hyper converged infrastructure, 예_뉴타닉스, 심플리비티, VMware 등) 에서 주로 사용하는 하드웨어 증가 방법이라고 생각하면 된다.

 반면 모든 서버가 동일한 데이터를 가지고 있어야 하므로, 데이터 변화가 적은 ‘웹 서버’에 더 활용을 많이 하고 있으나, 하드웨어 집적도가 계속 늘어나고 있고 성능도 월등히 좋아져 데이터 변화를 고려하지 않을 정도가 되었다.




2) 스케일 업

‘스케일 업’은 서버에 CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 방법을 의미한다. 예를 들어, ‘1’의 처리 능력을 가진 서버 한 대를 ‘5’의 처리 능력을 가진 서버로 업그레이드시키는 것이다.

CPU나 RAM을 추가하기로 했다면 현재 서버에 추가 부품을 장착할 수 있는 여유 슬롯이 있어야 하며, 그렇지 않은 경우 서버 자체를 고성능으로 교체하는 것이 필요하다.

스케일 업의 경우, 서버 한 대에 모든 부하가 집중되므로 장애 시 영향을 크게 받을 수 있는 위험성이 있으며. 한 대의 서버에서 모든 데이터를 처리하므로 데이터 갱신이 빈번하게 일어나는 ‘데이터베이스 서버’에 적합한 방식이다. 이 또한 위의 내용과 상충이 되는데 요새는 DB 서버도 스케일 아웃 방식으로 많이 구성한다.

스케일 업 방식의 서버 증가 방법엔 치명적인 단점이 있다. CPU나 메모리를 확장할 수 있는 슬롯이 있다 해도, 서버를 증설하고 싶을 시기에는 이미 그 슬롯에 맞는 CPU나 메모리는 시장에서 단종된지 오래인 경우가 많다.

그런 이유로 나는 스케일 아웃 방식의 하드웨어 증설 방법을 선호한다.



2016년 5월 13일 금요일

[DB] 티베로 DB HA구성

인프라 관리자의 숙명은 장애관리라고 생각하는 한 사람으로서 이번에는 DB와 관련된 HA구성에 대해 검토 했던 내용을 공유 하고자 한다.

기본적으로 HA라 함은 고가용성을 뜻하고 DB의 장애 발생시 최소한의 Downtime으로 서비스의 장애를 처리를 하게 해주는 것이다.

일반적인 HA는 노드간 Active - Standby로 구성되어 서로의 서비스를 체크하고 공유한다 서비스의 양호성은 서버에서 제공하는 HA 모니터링 툴을 이용하는 것이 일반적이라고 할 수 있다. 하나의 노드가 장애가 나면 해당 노드의 사용자 세션은 소실 되며 Standby 노드가 기동되는 시간 만큼의 다운타임이 발생하게 된다.

오라클이나 티베로 DB의 경우 HA이외에도 RAC/TAC라는 기능을 제공 하는데, 두 개의 노드를 Active - Active로 사용 할 수 있게 해준다. 이는 일반적인 HA와는 다르게 하나의 노드에 장애가 발생해도 다운타임이라는 개념이 거의 없다. 다만 장애 노드에 붙어 있던 세션은 소실 될 수 있다.
RAC/TAC 구성을 위해서는 파일시스템에 데이터를 구성하는 것이 아닌 RAW 디바이스에
스토리지를 할당하여 데이터 파일을 구성하게되어 있는데 이는 DB의 테이블 스페이스별 명명 규칙과 혼용하여 쓰기에는 비효율 적인 측면이 있다. GPFS (IBM 기준) 라는 솔루션을 구매한다면 파일시스템으로도 RAC/TAC 구성이 가능 하다.

두 가지 구성의 차이를 간단히 표로 정리하여 보았다.

2014년 11월 25일 화요일

[DB] Oracle Trouble shooting Example

Oracle 에러가 발생한 경우 구글링을 통한 문제해결도 좋지만.
Oracle에서 공식으로 지워하는 Oracle Support 페이지를 사용하는 것이 가장 현명하다. https://support.oracle.com/

2014년 7월 15일 화요일

[AIX] 이더넷 장비 확인

sapedu:/] lsdev -Cc adapter | grep ent
ent0    Available       Logical Host Ethernet Port (lp-hea)
ent1    Available 02-00 2-Port Gigabit Ethernet-SX PCI-Express Adapter (14103f03)
ent2    Available 02-01 2-Port Gigabit Ethernet-SX PCI-Express Adapter (14103f03)
ent3    Available 00-00 2-Port Gigabit Ethernet-SX PCI-Express Adapter (14103f03)
ent4    Available 00-01 2-Port Gigabit Ethernet-SX PCI-Express Adapter (14103f03)
ent5    Available       EtherChannel / IEEE 802.3ad Link Aggregation
sapedu:/] lsdev -Cc if
en0 Defined         Standard Ethernet Network Interface
en1 Defined   02-00 Standard Ethernet Network Interface
en2 Defined   02-01 Standard Ethernet Network Interface
en3 Defined   00-00 Standard Ethernet Network Interface
en4 Defined   00-01 Standard Ethernet Network Interface
en5 Available       Standard Ethernet Network Interface
et0 Defined         IEEE 802.3 Ethernet Network Interface
et1 Defined   02-00 IEEE 802.3 Ethernet Network Interface
et2 Defined   02-01 IEEE 802.3 Ethernet Network Interface
et3 Defined   00-00 IEEE 802.3 Ethernet Network Interface
et4 Defined   00-01 IEEE 802.3 Ethernet Network Interface
et5 Defined         IEEE 802.3 Ethernet Network Interface
lo0 Available       Loopback Network Interface
sapedu:/] netstat -v ent5 | grep Link
Link Status : Up
Link Status : Up
sapedu:/]

[DB] 오라클 리두로그 개념.

■ 리두로그 (Redo Log)

오라클에서 일어나는 트랜잭션에 대한 변경 내역 기록. LGWR(Log Writer) 의해 로그버퍼에 쓰여진 내용이 리두로그 파일에 기록됨.

리두로그 파일은 DB에 장애가 발생하였을때 데이터 파일에는 쓰여지지 않은 커밋된 데이터 복구용으로 사용되며 복구를 위해 사용된다.

참고> LGWR이 써지는 경우
1. Commit이 발생
2. Redo Log Buffer가 1/3이 찼을 때
3. 변경량이 1MB가 되었을때
4. 3초 마다
5. DBWR (DB Writer)가 내려쓰기 전

■ 리두로그의 상태
UNUSED : 리두로그 그룹이 사용된 적이 없음
INACTIVE : 현재 사용중이지도 않고 복구에도 필요없는 리두로그
ACTIVE : 복구에 필요한 리두로그
CURRENT : LGWR이 현재 기록중인 리두로그

■ 리두로그의 구성
물리적으로 다른 디스크를 분리하고 이중화 하여 가용성을 높일 수 있다.
Group은 최수 2개 (권장 3개), Member는 최소 1개 (권장 2개)
Member가 1개인 경우 불안정 할 수 있으므로 2개의 Member를 구성하는 것이 바람직하다.
(Member가 1개만 있다면 해당 그룹의 Disk가 장애가 나면 이 Group의 log data 유실 된다.)
같은 Group 의 Member 는 절대 동일한 디스크에 함께 두는 것을 권장하지 않는다. 만약의 경우 디스크에 장애가 날 경우, 그 Group 전체가 손상 될 수 있기 때문이다.


리두로그의 관리
- 리두로그 그룹 추가
ALTER DATABASE ADD LOGFILE
GROUP 1
('/home/oracle/인스턴스명/disk1/redolog01_01.log',
'/home/oracle/인스턴스명/disk2/redolog01_02.log') size 20m,
GROUP 2
('/home/oracle/인스턴스명/disk3/redolog02_01.log',
'/home/oracle/인스턴스명/disk4/redolog02_02.log') size 20m

- 리두로그 그룹 삭제
ALTER DATABASE DROP LOGFILE GROUP 1

리두로그 삭제시 REDO LOG 그룹의 상태가 CURRENT, ACTIVE 이면 삭제 불가능
LOGFILE SWITCH를 발생 시켜 INACTIVE 상태로 만들어야 함

- 리두로그 멤버 추가
ALTER DATABASE ADD LOGFILE MEMBER '/home/oracle/인스턴스명/disk3/redolog01_03.log'
TO ('/home/oracle/인스턴스명/disk1/redolog01_01.log','/home/oracle/인스턴스명/disk2/redolog01_02.log')

또는

ALTER DATABASE ADD LOGFILE MEMBER '/home/oracle/인스턴스명/disk3/redolog01_03.log'
TO GROUP1

- 리두로그 멤버 삭제
ALTER DATABASE DROP LOGFILE MEMBER '/home/oracle/인스턴스명/disk3/redolog01_03.log'

- 리두로그 강제 스위치
ALTER SYSTEM SWITCH LOGFILE

- 리두로그 상태 확인
SELECT * FROM V$LOG;
SELCECT * FREOM V$LOGFILE;