짜꾸미의골골몽

1. 백업할 VM 이미지 Clone

1) virt-manager에서 Clone

2) Command Line으로 Clone

virt-clone --original=[원래 있던 VM 이름] --name=[새로 만들 VM 이름] -f [생성할 img 파일 위치] --mac [랜카드 맥주소]

ex) virt-clone --original=testvm1 --name=newvm -f /var/lib/libvirt/images/skylit_newvm.img --mac 00:12:34:56:78:90

2. 백업 VM 이미지 및 설정파일 전송

1) 동일한 파티션 구조일 경우 생성한 VM 이미지 디렉토리와 동일한 곳에 전송(scp 또는 rsync)

2) 파티션 구조가 다를 경우 우선 전송 후 이후 xml 파일 수정(/etc/libvirt/qemu/[이미지명].xml

ex) scp Template_* root@192.168.0.58:/DATA/TS_VM/

ex) scp /etc/libvirt/qemu/[이미지명].xml root@192.168.0.58:/etc/libvirt/qemu

3. VM 복구

1) 복사한 VM을 virt-manager에서 인식 가능하도록 XML 설정 파일 define 실행

2) 복사한 이미지 서버의 파티션과 복사 완료된 서버 파티션 구조가 상이할 경우 xml 파일 편집 필요

3) virsh manager define 명령어 수행

virsh define /etc/libvirt/qemu/[옮겨온 VM 이름].xml

4. virt-manager 실행 후 추가된 VM 확인

출처 : https://skylit.tistory.com/195

CentOS 7.x 싱글부팅 및 root 패스워드 초기화

1. 부팅 시 커널 버전 선택 시 "e" 키 누른 후 수정

수정 항목 : rhgb quiet -> init=/bin/bash

2. 수정 완료 후 Ctrl + x 키로 싱글 부팅 진행

3. 패스워드 변경 진행

- passwd로 변경 시도 시 selinux 활성화 등으로 변경 불가

- SELINUX 활성화로 relabel 자동 수행하도록 추가 명령 수행

# mount -o remount,rw /

# passwd root

# touch /.autorelabel

# exec /sbin/init

출처 : https://imitator.kr/Linux/806

Oracle DBLink 설정

이관 대상 서버(A) --- DB Link --- 실 데이터 서버(B)

1. 이관 대상 서버(A)의 tnsnames.ora 파일에 실 데이터 서버(B)에 대한 접속 정보 추가

DBLINK =

  (DESCRIPTION =

    (ADDRESS_LIST =

       (ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.100.100) (PORT = 1521))

    )

    (CONNECT_DATA =

       (SID = linkdb)

    )

  )

2. DBLink 설정

이관 대상 서버(A)에서 실행하며 DBA권한이 필요

# sqlplus ‘/as sysdba’

# grant dba to linkuser;

# sqlplus linkuser/PASSWD

create database link 링크명 connect to 원격지서버계정 identified by 원격지서버패스워드 using ‘TNS명’;

SQL> create database link LINKTEST connect to linkuser identified by link11223344 using 'DBLINK';

3. DB Link 정상 확인 테스트

- 목록 조회 -

select * from user_db_links;

select * from all_db_links;

SQL> select * from data_table_1@LINKTEST

4. 원본 테이블 이관 대상 서버로 create 실행

SQL> create table data_table_new_1 as select * from data_table_1@LINKTEST;

5. DB이관 이후 DBLink 삭제

SQL> drop database link LINKTEST;

### 테이블 목록 추출 및 SQL 쿼리문 자동 완성 ###

select 'create table '||table_name||'  as select * from ' from all_tables where table_name like 'data_table%'

### 테이블 목록 추출 ###

select table_name from tabs where table_name like 'data_table%' order by table_name

### 기존 테이블 존재 시 조건을 통한 Insert ###

insert into data_table_new_1 select * from data_table_1@DBLINK where time >= to_date('2013-05-30 000000','YYYY-MM-DD HH24:mi:ss')

AND time < to_date('2013-05-30 180000','YYYY-MM-DD HH24:mi:ss');

[replication의 작동원리]

1. Master 서버에서는 bin-log를 로깅하면 binlog dump라는 프로세스가

Slave 서버에 이벤트를 보낸다

2. Slave 서버의 slve_io_thread 가 마스터의 bin-log를 복사해 온다.

3. 그후 slave_io_thread가 relay-log 를 로깅.

4. 다시 slave 서버의 slave_SQL_thread가 relay-log를 바탕으로 마스터의

SQL구문을 재생.(동기화)

위의 4단계가 리플리케이션의 작동원리 입니다.

Relay-log를 다시 재생하는 (slave_SQL_thread )과정에서  불필요한 부하가 생기는 방식이 아닌가 의문이 드시겠지만

Relay-log는 보통 운영체제의 캐시에 저장이 되므로 오버헤드가 매우 낮습니다.

위와 같이 슬레이브에서 이벤트를 가져오고 재생하는 과정으로 인해 리플리케이션은 비동기식으로 작동하게 됩니다.

따라서 특정주기로 리플리케이션의 복제가 일어나는 것이 아니라 마스터의 변경사항은 그 즉시 동기화가 됩니다.

동기화는 즉시 일어나지만 네트워크의 속도로 인하여 지연이 발생한다고 보시면 됩니다.

실제 테스트를 해보면

먼저 마스터 서버에서

Mysql > create table test.lag_test(

→ Id int not null auto_increment primary key,

→ Now_usec varchar(26) not null

→ );

Mysql > insert into test.lag_test(now_usec) values (now_usec());

다음 슬레이브에서

Mysql > create table test.master_val (

→ Id int not null auto_increment primary key,

→ Now_usec varchar(26) not null

→ ) engine=federated

→ Connection=’mysql://user:root@192.168.13.147/lag_test’;

TIMESTMPDIFF() 함수로 마스터와 슬레이브에서 실행된 쿼리의 지연시간을 마이크초 단위로

찍어보면

Mysql > select m.id , timestampdiff ( frac_second, m.now_usec, s.now_usec ) AS user_lag

→ From test.lag_test as s

→ Inner join test.master_val as m using(id);

+------+-------------------+

|  id   |  usec_lag      |

+------+-------------------+

|  1   |  476           |

+------+-------------------+

400밀리초가 소요 됨을 확인 하였습니다.

대부분의 작은 쿼리는 마스터의 실행 시간에서 슬레이브의 실행시간까지의 복제에 0.3밀리초가 걸립니다.

이론상으론 마스터에서 슬레이브까지의 복사시간은 거의 측정불가이며 네트워크 속도가 리플리케이션

복제 속도라고 이해하시면 되겠습니다.

덧붙여 슬레이브 상태정보를 통해 지연되는 정보확인은

Mysq >  show slave status\G

로 확인 하실수 있습니다.

*************************** 1. row ***************************

….(중략)…..

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

…(중략)…

Seconds_Behind_Master: 0

붉은색 표시된 이부분이 마스터와 슬레이브의 격차를 시간으로 표시하는 부분입니다.

…(중략)…

***************************************************************

MySQL Replication 설명

MySQL Replication이란?

MySQL Replication이란 단어의 뜻 그대로 복제입니다. 즉, 물리적으로 다른 서버의 저장 공간” 안에 동일한 데이터를 복사하는 기술입니다.

MySQL복제라는 말과 같이, 디스크를 독립적으로 분리하여 데이터를 유지합니다.

엄격하게 다시 말하자면, “MySQL Replication은 데이터를 이중화”하는 개념입니다.

MySQL은 오직 단일 마스터에서만 데이터 변경 작업을 수행할 수 있고,

그렇기 때문에 MySQL에서는 쓰기 부하 분산은 불가능하지만, 읽기 부하 분산은 가능합니다. 그리고 특정 노드 디스크 장애가 전체 데이터 유실로 이어지지 않습니다. 데이터가 “복제”되기 때문 입니다.

Master, Slave 간Data 복제 방법

MySQL Replication은 로그 기반으로 비동기적으로 데이터를 복제합니다. 마스터에서는 데이터 변경 작업이 수행되면 Binary Log라는 곳에 이력을 기록을 하는데, Statement, Row 그리고 Mixed 등 세 가지 방식이 있습니다.

Statement-based Type

MySQL 3.23 이후로 도입된 방식

실행된 SQL을 그대로 Binary Log에 기록

Binary Log 사이즈는 작으나, SQL 에 따라 결과가 달라질 수 있음

(Time Function, UUID, User Defined Function)

Row-based Type

MySQL 5.1부터 도입된 방식

변경된 행을 BASE64로 Encoding하여 Binary Log에 기록

특정 SQL이 변경하는 행 수가 많은 경우 Binary Log 사이즈가 비약적으로 커질 수 있음

Mixed Type (Statement + Row)

기본적으로 Statement-Based Type으로 기록되나, 경우에 따라 Row-base Type으로 Binary Log에 기록

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

• 단순 Insert/Update/Delete에서는 Binary Log를 Row based로  설정 시 Statement Based 보다 Master/Slave 간 데이터 시간 차가 20~30% 적게 발생함

• Semi-synchronous Replication 테스트에도 Row based 성능이 Statement Based보다 20~30% 나은 결과를 보임

• Grouping SQL 에서는 Row based가 서버 간 시간 차가 거의 발생하지 않음

보기에는 Row Based 퍼포먼스가 뛰어난 것을 보실 수 있습니다.

특히나 Master 서버에 집계성 SQL이 Insert..Select 또는 Create table as Select 형태로 구성되는 로직이 많다면 더욱 유리합니다.

하지만!!

Row Based Binary Log는 5.1 버전부터 도입된 방식으로 아직까지도 여기저기 버그가 있습니다.

특히나 PK 가 없는 대용량 테이블을 대량으로 수정하게 되면, Slave서버에서는 해당 시점에서 멈추는 현상이 발생합니다.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

저희 권고하며 가장 많이 쓰는 방식은 Mixed Type 방식 입니다. SKT에서도 Mixed Type 으로 Replication 동기화를 표준화 하고 있습니다.

그렇다면 복제는 어떤 방식으로 이뤄질까요? 아래 그림으로 설명 드리겠습니다.

• Master에서 데이터 변경이 일어나면 자신의 데이터베이스에 반영합니다.

• Master에서 변경된 이력을 Binary Log에 기록 후 관련 이벤트를 전달합니다.

3. Slave IO_THREAD에서 Master 이벤트를 감지하고,

Master Binary Log 자신의 Relay Log라는 곳에 기록을 합니다.

4. Slave SQL_THREAD는 Relay Log를 읽고 자신의 데이터베이스에 기록을 합니다.

기억해야할 사항은 마스터에서는 여러 세션에서 데이터 변경 처리가 가능하지만(멀티스레딩), 슬레이브에서는 오직 하나 SQL Thread에서만 데이터 변경 처리가 가능한 점입니다. 그렇기 때문에 마스터에 데이터 변경 트래픽이 과도하게 몰리게 되면 마스터/슬레이브 간 데이터 동기화 시간이 크게 벌어질 수도 있습니다.

※ Multipath

스토리지에서 제공되는 디스크 볼륨(LUN)이 Path가 이중화 되어 제공 될 때,

OS에서는 동일한 디스크 볼륨이 여러개로 보이게된다.

이 부분을 하나로 만들어주며, Path 하나가 장애 발생 시 다른 Path로 I/O를 Failover 시켜주는 솔루션

현재 리눅스상에 설정되어 있는 솔루션은 RHEL 기본 제공 device mapper multipath

상용 솔루션으로는 EMC PowerPath, Hitachi HDLM 등이 있음

※ Multipath 명령어

multipath -F                         // 초기화

multipath -v2                        // 적용

multipath -ll                        // 적용 리스트 확인

multipath -v3 | grep blacklist        // blacklist 설정 확인

LUN 할당 시 크기가 큰 덩어리 1개보다 분할하여 LUN할당하는 것이 효율적이다

볼륨사이즈가 클 수록 fsck 작업 등을 수행 시 시간이 많이 소요된다.

MTU (Maximum Transmission Unit)

1. MTU(Maximum Transmission Unit)이란…

MTU란 TCP/IP네트웍 등과 같이 패킷 또는 프레임 기반의 네트웍에서 전송될 수 있는 최대 크기의 패킷 또는 프레임을 말합니다

한번에 전송할 수 있는 최대 전송량(Byte)인 MTU 값은 매체에 따라 달라집니다.

예를 들어 Ethernet 환경이라면 MTU default 값은 1500 이고 FDDI 인 경우 FDDI는 4000 정도 되고, X.25는 576, Gigabit MTU는 9000 정도 등 매체 특성에 따라 한번에 전송량이 결정됩니다.

2. ADSL에서의 MTU값

ADSL은 PPPOE와 PPPOA를 사용합니다. 외장형모뎀과 PC Lan 카드를 사용하는 형태는 PPPOE(PPP over Ethernet)라고 합니다

PC에서 만들어진 Ethernet frame 이 ADSL serial 구간을 그냥 통과하지 못하기 때문에 이더넷 Frame 안에 PPP frame을 포함해서 전송하기 때문에 1500 보단 작아야 합니다.

참고로 접속프로그램중 Winpoet은 MTU를 1420으로 설정하고 Ethernet 프로그램은 MTU를 1416 정도로 설정합니다.

<일반적인 Ethernt 에서의 TCP/IP 패킷 >

< PPPOE 에서의 TCP/IP 패킷 >

3. MTU값 계산

MTU는 Ethernet Frame을 제외한 IP datagram 의 최대 크기를 의미합니다.

즉 MTU 가 1500 이라고 할 때 IP Header의 크기 20 byte 와 TCP Header의 크기 20byte를 제외하면 실제 사용자 data는 최대 1460까지 하나의 패킷으로 전송 될 수 있습니다.

Windows 계열에서는 PC의 기본 MTU가 1500으로 설정되어 있습니다. 레지스터리에 특정 값을 적어주지 않으면 자신의 MTU값을 1500으로 설정됩니다. 그러나 Win2000부터 Media의 특성을 인식하여 dynamic하게 MTU를 설정됩니댜.

4. MTU값 조정

Unix, Linux 계열에서는 ifconfig 명령어로 쉽게 변경할 수 있습니다.

예) ifconfig hme0 mtu 1400

    ifconfig eth0 mtu 1300

Windows 계열은 레지스터리를 수정하면 되며 OS 버전에 따라 설정값이 달라집니다

 w

MSS (Maximum Segment Size)

-> 최대 전송 사이즈를 의미

MSS 를 1000 으로 설정할 경우, 데이터 전송시 최대값 1000 byte 이내에서 데이터를 나누어 전송하게 됩니다.

1500 byte의 데이터 전송시 988 byte 전송 이후 512 byte만 전송

MSS 에서 user data( 12byte ) 를 제외한 데이터 988 byte가 실질적인 데이터 전송 사이즈가 됩니다.

User data ( The 12 byte of user data contain a sequence number that is incremented each time a datagram is sent, a copy of the outgoing TTL,

And the time at which the datagram was sent )

MSS는 Maximum Segment Size의 약어로 TCP상( TCP/UDP 가 아니라 그냥 TCP입니다 )에서의 전송할 수 있는 사용자 데이타의 최대크기입니다.

MSS 값은 기본적으로 설정된 MTU 값에 의해 결정됩니다.

MSS= MTU-(IP header크기) - (TCP header크기)

그러므로 Ethernet 일 경우, MTU 1500에 IP 헤더크기 20byte TCP 헤더 크기 20byte를 제외하면 1460 이 MSS 값으로 됩니다.

TCP로 통신할 때는 통신 양단간에 서로 MSS값을 주고 받습니다.

TCP는 3-way 핸드쉐이킹으로 session을 establish 하며 이 과정 중에 상대방에게 자신의 MSS 값을 알려 주게 됩니다.

<  3-way Hand shaking 과정 >

 Client                                                              Server

                            < SYN, MSS=1380 >

( MTU 1420 )     ------------------------------------->  ( MTU 1500 )

                            < SYN,ACK, MSS=1460>

               <-------------------------------------

                             < ACK >       

                 ------------------------------------->

위의 그림처럼 Client 의 MTU 가 1420 이고 Server 의 MTU가 1500 라고 가정할때 클라이언트가 초기 TCP  세션을 성립하기 위해 Syn패킷을 서버로 보낼때 TCP Header의 option 필드에 MSS값을 설정하여 서버로 전달합니다.

그러면 서버는 SYN, ACK 를 보내면서 역시 TCP 헤더 옵션에 자신의 MSS 값을 보냅니다. 그러면 세션이 성립되어 패킷을 전달할때 실제 단위 패킷의 사이즈가 1420을 초과하지 않게 패킷을 나누어서 전송하게 됩니다.

서버는 자신의 MTU가 1500 이라고 해서 패킷을 1500 단위로 나누지 않습니다. 만약 패킷을 1500 크기로 보내면 client에서는 자신의 용량을 초과하기 때문에 데이타를 수신할 수 없게 됩니다.

# systemctl get-default

-> 현재 설정 확인

# systemctl list-units --type=target

-> 변경 가능한 목록 확인

# systemctl set-default multi-user.target

-> 런레벨 3으로 변경

# systemctl set-default graphical.target

-> 런레벨 5으로 변경

# systemctl set-default graphical.target

Removed symlink /etc/systemd/system/default.target.

Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target.