ISL 이해, 손쉬운 SAN 구현의 첫걸음
스토리지 용량·확장성 고려해 환경 선택해야 … C2E 비용·확장성 우수

서범석 // 맥데이터코리아 차장 bomseok.seo@mcdata.com

SAN은 가장 보편화된 기업 스토리지 구성방법으로 자리잡고 있다. 하지만, 아직도 상당수의 관리자가 SAN을 복잡하고 어려운 것으로 느끼고 있는 것 또한 사실이다. 하지만, ISL(Inter Switch Link)을 이해한다면, SAN은 복잡하고 어려운 것이 아닐 수 있다. SAN의 ISL 구성에 대해 알아본다. <편집자>

오늘날 기업 환경은 빠르게 IT 의존적으로 변해가고 있다. 많은 기업이 기업의 경쟁력을 높이기 위해 IT인프라를 보강하고, 그 효율성을 극대화하기 위해 많은 고민을 하고 있는 상태다. 그렇지만, IT환경을 업그레이드하는 것은 많은 예산 투자를 필요로 하는 까닭에 매우 신중한 결정을 요구하는 일임에 틀림없다.
이에 대한 해결책의 하나로, 고가의 스토리지를 네트워크로 연결·공유함으로써 스토리지의 추가 구입을 방지하고, 예산을 절약할 수 있는 SAN 도입이 늘고 있다. 이처럼 다양한 장점을 가진 SAN 도입이 점차 보편화되고 있음에도 불구하고, SAN에는 복잡하고 어렵다는 막연한 오해가 아직도 존재하고 있다.
하지만, ISL(Inter Switch Link)을 정확히 이해한다면, SAN에 대한 오해는 불식될 수 있을 것이다. ISL에 대한 이해 하에서 SAN을 디자인 한다면, 향후 문제를 야기하거나 성능을 저하시키는 SAN 디자인을 방지할 수 있는 것이다. 이 글에서는 ISL의 여러 특징들에 대해 설명하고자 한다.

FC프로토콜 이중구조는 ‘양방향 통로’
우선, SAN을 통한 물리적인 데이터의 통로와 이 통로에서 실제로 발생하는 데이터의 흐름의 차이를 알아야 한다.
파이버 채널 프로토콜은 이중 구조의 프로토콜이다. 흔히 이 이중 구조를 데이터 저장을 위한 쓰기 전용 통로와 데이터를 불러올 때를 위한 읽기 전용 통로로 이해하기 쉽다. 그러나, ISL이 구현돼 있다면, 하나의 스위치에 연결된 읽기 통로가 다른 스위치의 쓰기 통로로 변환될 수 있다. 즉, 쓰기 통로와 읽기 통로로 이분화시켜 이해하는 대신 두 스위치 사이에 데이터의 이동 통로가 두 개 있다고 이해해야 한다.
서버는 데이터를 스토리지로부터 읽을 수 있고, 스토리지에 저장할 수도 있는데(데이터를 읽거나 저장한다는 것은 데이터의 흐름이 있다는 얘기다) 보통은 데이터를 읽는 것은 읽기 통로를 통해 이뤄지고, 저장은 쓰기 통로를 통해 이뤄진다고 생각하지만, 이와 달리 ISL에서는 양방향 소통이 가능한 두 물리적인 통로가 존재한다고 생각하면 되는 것이다. 하나의 물리적인 통로는 스위치 X에서 스위치 Y로의 데이터 이동을 가능하게 하고, 다른 물리적 통로는 스위치 Y에서 스위치 X로의 데이터 이동을 가능하게 한다. 다시 말해, 읽기 통로와 쓰기 통로가 있는 것이 아니라, 통로 A와 통로 B가 있다라고 이해하면 되는 것이다.
서버는 데이터의 흐름을 통해 스토리지로부터 데이터를 읽을 수도, 저장할 수도 있다. 우리는 하나의 물리적 통로를 넘어 토폴로지를 통해 흐르는 것처럼 데이터 읽기와 다른 물리적 통로를 넘어 토폴로지를 통해 데이터 쓰기를 생각한다. 현실상에서, 모든 데이터 흐름은 모든 물리적 통로를 통해 전송된다.

일반ISL과 메시ISL
ISL의 양식은 두 가지 타입이 있다. 첫번째는 전형적인 ISL 양식의 ‘일반ISL(Normal ISL)’이다. 매우 단순한 양식으로 쓰기와 읽기를 하나씩의 통로로 지정, 쓰기 통로와 읽기 통로로 구별하여 관리하는 것이다.
예를 들어, 서버가 스토리지에 쓰기를 할 때 데이터는 통로 A를 통해서 전송하고, 통로 B는 사용하지 않는다. 반대로 스토리지로부터 서버가 데이터를 읽을 때 데이터는 통로 B를 통해 받게 된다. 이러한 양식은 SAN에 수많은 서버와 스토리지가 연결돼 있어도 마찬가지다. 쓰기와 읽기를 위해 절대 같은 통로를 이용하지 않는다. <그림 1>은 일반ISL 양식을 설명한 토폴로지이다.
만약 50개의 서버가 있다고 가정한다면, 그 중 49개가 스토리지에 쓰기를 하고 있다고 하더라도 50번째 서버가 스토리지로부터 읽기를 할 때 어떠한 방해도 받지 않는다. 그러나, 49개의 서버들에 의해 사용되는 물리적 통로는 병목현상이 나타나게 될 것이고, 50번째 서버는 하나의 통로의 대역폭을 온전하게 사용할 수 있다.
ISL의 두번째 양식은 ‘메시ISL(Mesh ISL)’로 그물망처럼 통로를 만들어 관리하는 것이다. 메시ISL 기능에서는 하나의 통로가 쓰기와 읽기에 모두 사용될 수 있다. <그림 2>는 메시ISL 양식을 설명한 토폴로지다.
만일 서버1이 스토리지 B로 읽기를 하고 있는 것과, 서버2가 스토리지 A로부터 쓰기를 하는 것이 동시에 일어나고 있다면, 이 두 데이터의 흐름 모두 ISL 2를 동시에 통과하려 할 것이다. 여기서 ISL1과 ISL3은 일반ISL이며, ISL2는 메시ISL이다. 만약 스위치 A에 연결된 49개의 서버가 동시에 스토리지 B에 쓰기를 하고 있다면, 스위치 B와 C사이의 데이터 통로인 ISL2는 포화상태에 이르게 될 것이며, 서버2가 스토리지 A로부터 읽기를 동시에 하고 있다면 같은 ISL2를 지나야하므로 읽는 속도에도 영향을 미칠 것이다.
메시ISL을 구현한다면, 데이터의 쓰기와 읽기 시 같은 데이터 통로를 공유할 수 있게 돼 결과적으로 서로의 속도에 영향을 주게 된다. 또한, 어느 한 물리적인 통로가 포화 상태가 돼 문제를 일으킨다고 해도 그 이유를 판단하기 어렵게 된다.
<그림 2>에서, 서버1과 서버2가 각각 대역폭의 60% 정도를 필요로 한다고 가정한다면, ISL1과 ISL3에서는 데이터 이동에 아무런 문제가 발생하지 않겠지만, 이 둘이 동시에 ISL2를 통해 이동하려 한다면, ISL2는 포화상태에 빠져버리게 되며, 이 상황에서 HBA와 스토리지 포트의 사용량을 측정한다고 해도 성능 문제를 일으킬 정도로 과용된 포트를 찾을 수 없게 될 것이다. 만약 SAN의 구현을 통해 데이터의 흐름을 정확하게 이해하고 있지 않다면, 문제의 발생 원인을 찾는 것이 매우 어렵게 된다.
메시ISL이 구현돼 있다면 데이터의 통로가 포화 상태가 됐을 때 문제를 진단하기가 매우 힘든 것이다. 일반ISL에서는 데이터 쓰기의 정점을 파악해서 미리 ISL의 포화 상태가 되는 것을 방지할 수 있지만, 메시ISL에서는 문제 발생 시 단순하게 하나의 물리적 통로에서 하나의 데이터 흐름만 확인하는 것뿐만 아니라 모든 데이터 흐름을 확인해야 한다.
따라서 메시ISL이 구현돼 있다면, 하루 동안 일어나는 데이터의 흐름을 파악하는 데 신중을 기해야 한다. 데이터의 쓰기가 오전 9시에 대역폭 점유율이 80%로 정점에 이르렀고 데이터의 읽기가 10% 미만이었다고 가정한다면 아무런 문제가 발생하지 않겠지만, 오후 2시에 데이터의 쓰기에 필요한 대역폭 점유율이 50%이고 데이터의 읽기에 필요한 대역폭이 60%라면 문제가 발생하게 된다.

SAN 토폴로지
SAN의 토폴로지에는 플랫(Flat), 메시(Mesh), C2E (Core-to-Edge)와 같은 세 가지 타입의 토폴로지가 존재한다. 가장 단순한 플랫(Flat) 토폴로지는 ISL을 구현하지 않는다. 플랫 토폴로지는 하나 이상의 서버나 스토리지가 서로 다른 스위치에 연결된 토폴로지이다. 서버는 같은 스위치가 연결된 스토리지에만 엑세스 가능하고, 다른 스토리지에 다양한 연결(any-to-any)은 할 수 없다.
메시 토폴로지는 플랫 토폴로지와 ISL이 함께 구현돼 다양한 연결(any-to-any)을 가능하게 해준다. 메시 토폴로지는 보통 한쪽의 스토리지의 저장 공간이 부족하고, 다른 한쪽의 스토리지의 저장 공간이 충분할 때 많이 구현한다. 새로운 스토리지를 구입하는 대신에 ISL이 모든 스위치를 연결해 다양한 연결성(any-to-any)을 제공할 수 있도록 한다.
성능을 가장 최적화하기 위해서는 메시 토폴로지 디자인을 할 때 서버와 그 서버가 가장 빈번하게 액세스 하는 스토리지를 같은 스위치에 연결될 수 있도록 하는 것이 좋다. 이 경우 스위치 간의 트래픽이 최소화돼 ISL의 대기 시간이 최소화될 수 있다.
ISL은 다양한 연결성을 필요로 할 때만 구현하도록 하는 컨피규레이션이 가능하며, 또한 테이프 드라이브와 같은 자원을 공유해야 할 때도 사용할 수 있다. 여기서 주의해야 할 점은 메시ISL의 구현이 테이프 작업을 삭제시킬 수 있으므로 메시 토폴로지에서 테이프 자원을 공유하려 한다면 사전에 주의 깊은 계획이 필요하다.
ISL의 대기시간은 2마이크로초가 안 될 정도로 매우 미미해 대부분의 애플리케이션에서는 거의 문제가 되지 않는다. 이 정도의 대기시간이 문제가 된다면 플랫 토폴로지를 구현해야 할 것이다.
코어-투-에지(C2E) 토폴로지는 기기의 위치가 중요한 토폴로지다. 특히, 코어 스위치에는 모든 스토리지 기기가 연결돼 있는 것이 특징적이다. 또한, 테이프 장비나 테이프 미디어 서버, 티어1 서버 등을 연결할 수도 있다. 여기서 티어1 서버가 ISL의 대기시간이 문제될 수 있는 애플리케이션이다. C2E를 디자인 할 때, 코어 스위치는 성능과 가용성을 고려하여 통상 디렉터급 스위치로 구현한다
에지 스위치에는 서버가 연결돼 있고, 보통 디렉터급 스위치나 하위급의 스위치 둘 중에서 선택할 수 있다. 에지에 어떠한 종류의 스위치를 구현해야 하는지 결정하는 데는 여러 가지 요소를 고려해야 한다. 에지 스위치는 서로 연결되지 않고, 코어 스위치에만 ISL로 연결돼 있다. C2E 설계의 장점은 오직 일반ISL을 사용한다는 것이다. 이러한 토폴로지는 확장이 매우 쉽다. 또한 스토리지, 서버, 스위치를 추가 연결하면 되기 때문에 ISL을 적게 사용해 메시 토폴로지보다 저렴하게 구현할 수 있다.

메시 디자인과 C2E디자인
먼저 메시 디자인에 대해 먼저 설명하도록 하겠다. 앞에서 설명한 바와 같이, 스위치A에 연결된 서버는 스위치A에 연결된 스토리지만을 사용하고, 같은 방법으로 B와 C와 D의 스위치에서도 각각의 서버가 같은 스위치에 연결된 스토리지만을 사용한다. 또 ISL은 필요시에만 구현된다고 가정한다. ISL이 구현되지 않았을 때에는 대역폭의 포화상태 문제도 발생하지 않는다.
그러나, 스위치A의 스토리지의 저장 공간이 모두 소비됐고 스위치C에 연결된 스토리지에 여유 공간이 남아 있다면, 저장 공간이 더 필요한 스위치A를 위해 새로운 스토리지를 구매할 것인지, 아니면 스위치C의 스토리지를 사용할 수 있도록 하는 것이 좋은 지 고려해야 한다.
스토리지의 가격은 매우 고가이기 때문에 보통 ISL을 구현하는 것을 고려하는 것이 경제적이다. 만약 ISL의 구현을 고려하지 않는다면 처음부터 플랫 토폴로지를 구현하는 것이 좋다. 각각의 스위치에 연결된 스토리지의 사용량이 모두 다르다면, 저장 공간이 충분한 스토리지를 사용하기 위해 ISL이 구현될 것이다. 이 때, ISL은 메시ISL 양식으로 구현된다.
결과적으로는 모든 스위치에 연결된 스토리지들의 저장 공간을 모두 사용하게 될 것이고, 추가 스토리지의 도입을 필요로 할 것이다. 예를 들어, 한 개의 스토리지가 모든 서버들이 필요한 스토리지 용량을 수용할 수 있다면, 스토리지 하나를 구입해 공유하는 것이 각각의 서버에 하나씩의 스토리지를 추가 도입하는 것보다 훨씬 저렴할 수 있다. 이 때 추가된 스토리지를 어느 스위치에 연결하는 것이 좋은지 결정해야 한다.
새로운 스토리지에 연결된 서버는 ISL을 필요로 하지 않지만, <그림 3>에서처럼 다른 세 스위치는 새로운 스토리지에 저장하기 위해 ISL 구현을 필요로 한다. ISL 구현 증가는 메시ISL의 사용 빈도를 증가시킬 것이고, 병목 현상을 진단하는데 어려움이 따를 것이다.
데이터량이 증가함에 따라 스토리지와 서버의 추가 도입 필요성은 점차 증가할 것이고, 이에 따라 스위치 포트도 더 필요하게 될 것이다. 스위치의 추가 도입 시 차후에 있을 서버나 스토리지, 테이프 드라이브의 추가 도입을 고려해 어디에 스위치를 추가할 것인지를 결정해야 한다. 만약 메시ISL을 전체적으로 처음부터 다시 디자인해야 한다면 이는 IT관련 기술자들이 꺼리는 방법이 될 것이다.
메시ISL 토폴로지와는 다르게 C2E 토폴로지의 경우, 모든 에지 서버들은 코어 스토리지에 엑세스가 가능하다. 스토리지를 추가할 때에도 코어에 추가하면 된다. 이러한 방법은 앞에서 새로운 스토리지를 어느 스위치에 연결해야 하는지의 문제를 해결하며, 새로운 서버는 역시 에지 스위치에 연결하면 된다. 이 경우 일반ISL은 서버나 스토리지의 추가에 관계없이 유지된다. 만약 에지 스위치 포트가 모두 사용되면 관리자가 중단이나 재설계 등의 어려움 없이 새로운 에지 스위치를 코어 스위치에 ISL로 연결하면 된다. 코어 포트가 모두 사용될 때쯤이면, 현재 기술의 발전 속도로 볼 때 용량이 더 큰 디렉터급의 SAN 스위치가 개발될 것이다.
현재의 코어 스위치를 새로운 디렉터급 스위치로 대체하고, 그 코어 스위치를 다시 에지 스위치로 재활용하는 방법은 매우 간단하다. 필요로 하는 포트의 증가 속도가 현재 기술이 지원할 수 없는 수준이거나 코어 스위치를 에지 스위치로 전환하고 싶지 않다면, 단순히 코어 스위치를 한 개 더 추가하는 방법도 있다.
맨 처음 패브릭을 디자인할 때는 정해진 수의 서버와 스토리지를 연결하도록 디자인하게 된다. 하지만 그 디자인에 추가 장비를 도입할 경우, C2E 토폴로지가 메시 토폴로지보다 훨씬 손쉽게 확장될 수 있다. C2E 디자인에서는 메시ISL이 전혀 구현되지 않기 때문에 새로운 장비의 추가 설치 문제가 매우 간단하다. 메시ISL도 처음에는 일반ISL만을 구현하지만, 데이터의 양이 증가함에 따라 메시ISL을 구현하게 된다.

C2E 비용측면 유리
비용적인 측면을 검토해 보자. ISL의 구현은 많은 비용이 든다. ISL을 구현함으로써 2개의 포트씩 사용되기에 그만큼 다른 제품에 연결할 수 있는 포트가 줄어들게 된다. 그러므로 ISL을 많이 구현하면 할수록 더 많은 포트가 필요하게 되어 비용 증가를 유발하게 된다. <그림 4>는 ISL4, ISL5, ISL6 들이 C2E 디자인에 추가된 것을 제외하고는 위에서 설명한 <그림 3>과 같다.
위의 두 토폴로지는 같은 토폴로지로서 단지 그림이 다르게 그려졌을 뿐이다. 자세히 관찰하면 같은 ISL이 각각 같은 스위치에 연결된 것을 알 수 있다. 만약, 이 디자인의 에지에 ISL을 추가하면, C2E 디자인은 메시 디자인으로 변환 가능하며, 이 두 디자인의 다른 점은 단지 디바이스들이 어떻게 연결됐는지의 차이일 뿐이다. 위의 C2E 디자인에서 스위치 A는 모든 스토리지에 연결돼 있지만, 서버는 하나도 연결돼 있지 않다. 이와는 반대로 스위치 B, C, D는 스토리지와 연결돼 있지 않다. <그림 4>에 있는 두 토폴로지가 같기 때문에 문제는 어떻게 디바이스들을 스위치에 연결할 것인가이다. 만약 왼쪽의 디자인을 선택할 경우, ISL4, ISL5, ISL6은 필요치 않다. 따라서 보다 저렴한 구현이 가능하다.
마지막으로 스위치에 대해 논의해 보겠다. 몇몇 제조사들은 메시ISL 디자인을 스위치 백플레인으로 사용하는데, 이는 포트간의 대기시간의 차이에 의해 결정된다. 대기시간의 차이는 메시ISL로 디자인된 백플레인과 함께 블로킹 아키텍처와 다르게 구별되고, 실제로 제조사는 한 제품에 두 가지 모두 사용하기도 한다.
블로킹은 백플레인이 동시에 모든 포트 수행을 처리할 수 있는 충분한 대역폭을 갖고 있지 않다는 것을 의미한다. 이는 한 슬롯 내에 너무 많은 포트가 있거나, 한 섀시 내에 포트가 너무 많기 때문에 발생한다. 이러한 문제는 새로운 기술을 도입할 때도 발생할 수 있다. 새로운 고속 포트 보드를 연결할 경우, 포트들이 같은 속도에서 최고의 가용성을 발휘할 수 있도록 설계된 새로운 고속 포트의 가용성을 충분히 발휘하도록 허용할 수 있는 충분한 대역폭을 기존의 백플레인이 갖고 있지 못하기 때문이다.
반면, 포트간에 서로 다른 대기 시간은 백플레인 상에서 하나의 포트에서 스위치를 통해 다른 포트로 옮겨갈 때의 트래픽을 보여준다. 두 포트간의 대기 시간이 존재하지 않는다면 데이터는 홉핑할 필요가 없다. 만약 약간의 대기시간이 있다면, 다른 포트로의 이동을 위해 한 번의 홉핑을 할 것이다. 또한, 대기 시간이 많이 늘어난다면, 여러 번의 홉핑을 통해 다른 포트로 이동할 것이다.
메시 토폴로지를 구현한 백플레인과 연결된 스위치의 성능에 문제가 생겼을 때 문제점을 파악하는 것은 거의 불가능에 가깝다. 병목 현상이 토폴로지에 있을 수도 있고, 스위치에 있을 수도 있고, 또는 둘 다에 있을 수도 있기 때문이다. 또한, 케이블 하나를 하나의 포트에서 다른 포트로 변경하는 것 또한 여러 포트 또는 스위치 전체에 새로운 성능 문제를 일으키는 원인이 되기도 한다.
메시 토폴로지에서도 서버와 스토리지를 하나의 스위치에 연결하면 ISL이 실질적으로 사용되지 않을 것이고, 또한 ISL 대기시간이 없을 것이다. 그러나 데이터의 증가로 인해 ISL이 구현되기 시작하면 대기 시간도 늘어나기 때문에 메시ISL을 디자인할 때는 이러한 문제를 충분히 고려해 디자인해야 한다. 이와는 반대로, 정확한 C2E 디자인은 서버와 스토리지를 중단 없이 확장 가능하며, ISL의 대기시간과 오류의 확률을 최소화할 수 있다.
서로 다른 ISL 타입을 정확하게 이해해야만 실정에 맞는 SAN을 디자인할 수 있을 것이다.