09-05 Solution Engineer

ㅁ Solution Engineer 

H/W(server, storage, netowrk) , S/W(Security solution , ERP etc...) 

Vendor의 Solutions를 Client에게 Delivery하는 역할. 

NSX, Tanzu 등 Solution을 Client들이 잘 사용할 수 있도록 설꼐 하는 작업을 한다. 

유지보수 계약을 맺고, 설계한 부분이 정상작동 하는지 monitoring하는 역할. 

>>> H/W, S/W든 Client가 원하는 IT Infra(Service) 설계/유지보수 하는 역할! 

 

ㄴ 업무 범위

고객이 필요로하는 기술 제안 및 제공(ex. homepage가 필요해요 : 거기에 맞는 기술, 제품 solutions )

고객이 제안을 받아들였을 경우 Needs에 맞는 적절한 환경 및 solution 설계 및 구현

(* 대부분의 solutions는 불완전 하기 떄문에, Bug나 hotfix가 늘 있다.)

고객의 IT infra service에 대한 안정적인 환경 유지보수 및 문제 해결

 

ㄴ 업무 자세

Engineer간 Solution 및 기술에 대한 정보 및 문제 Trouble shooting 공유!

> 상호 발전의 기회이자 수단의 목적.

> 회사에서 업무 수행을 할 때는 서로 알고있는 기술을 공유해서 빠른 처리와 더 많은 업무를 요할 수 있기떄문에.....

Vendor의 Solution에 대한 제약사항이나, Manual 이 있기 때문에, Client에게 전달 할 때에는 공식문서에 대한 Guide를 해야하는게 원칙(정확한 정보전달)이며, 개인적 해결방법(know-how)에 의존한 해결책 제시는 지양!!!!!

최근 VMware의 vSphere 8.0 버전의 출시로 공부 해야 할 게 많아질듯.

7.0 버전이후 Upgrade Version이기 때문에, 이전에 없던 기능이 생기기 떄문. 

Public CLoud와 유사한 형태로 Infra 구현 가능해질듯.

>>> 내가 언젠가는 지원,Delivery 해야하는 Serive이기 때문에, 항상 Vendor의 new solution, products 늘 동향 파악을 해야하고 Engineer간 공유, 질문 등 같이 성장...

VMware의 기본되는(Focus on products) Products, Solutions 를 늘 알고 있어야하고 모르면 물어야하고 알면 공유해야한다. 매번 급격히 변하는 Trend....

 

ㄴ 요구 역량

IT 기술 Trend는 급변하기 떄문에, 항상 배우고 동향 파악을 하고 그에 맞는 Client의 Needs를 파악해야 한다. 

근데 그럼에도 Engineer간 기술 공유를 해야하는 이유는 나만 알고 있어봤자, 나한테만 일이 몰릴뿐 ...

Engineer는 제안/설계&구축/유지보수 잘 하면 된다 물론? Client의 Needs를 끊임 없이 파악하고 그에 맞는 Serivce

 

ㄴ 업무보고(기술공유)

Outlook 업무보고서를 통해, 어떤 Engineer가 어떤 Solution을 어떻게 service 했는지 알 수 있기 때문에, 늘 참고 해두면 좋다. 

ㄴ 산출물작성(자료열람 및 공유)

---

ㅁ System Infra 

Infra Environment(Server, Storage, Network)에 대한 전반적 이해, 또 변화 하는 Solution들에 대한 동향파악 및 이해

ㄴ Server system

1.  on-premise Infra - Data-center & Server실에서 Infra 직접 관리 

Guest OS 위에 여러 Application을 설치할 경우 OS의 결함으로 인해 모든 Application의 장애가 발생할 수 있어 Risk가 큰데, 해결방법은 Application마다 Server를 구비하면 되는데, 이렇게 되면 기하급수적 비용이 발생한다. 이를 극복하고자 하는게 Virtualization 이다. 

가상화의 가장 큰 목적은 Resource를 공유하되, 서로에게 영향을 미치지 않기 때문에, 비용의 절감. 확장성 유연성등에 장점을 가지고있다. 

2.  Cloud Infra 

AWS, GCP, Azure 등과 같은 Public Cloud 방식을 사용하고 있는 방식.

국내는 아직 main이 되는 Service에 대해 Public Cloud 선호도는 낮다. 

(Ex. 국내 공공기관들도 모두 server전산실을 모두 갖고 있었는데, Data-center, Cloud로 미미하지만 점점 넘어가고 있는 단계임.)

3. Sysstem Architecture에 따른 구분 = Unix System / x86 System

Unix < x86 의 성능과 안정성이 높아져서 비용절감과 성능적 performance를 기대할 수 있기 때문에 

HP, Cisco 등 Vendor들이 모두 x86을 많이 채택하고 있다. 

cf) AWS 등의 Public Cloud Service Provider는 다름

ㄴ Blade Server

커다란 Chasis 안에 Slot들이 있는데, 이 Slot에 Server를 넣어 구축.

전력적으로 효율성도 높고 깔끔함 매우 좋음 Cabling에 대해서도 통합할 수 있는 환경임. 

ㄴ Rack Server 

Server의 크기도 크고 전산실의 면적등 많은 고려사항이 있고, Cabling의 경우 서버 한대당 10개 씩이라 해도 수가 많아지기 떄문에 단점이 있음.

사전체크 할 시에는 Client 에게 모든 정보공유를 하되, 의사결정은 Client의 몫이다. 그렇기 떄문에, 기술지원이 더이상 되지 않는 제품들에 대해 사전 검토를 하고 Upgrade등의 제안을 미리 해야한다.

4. System 구성 방식에 따른 구분 = RACK Type / Blade Type 

ㄴ Network system

L2, L3, L4, Backbone Switch 

Server, Storage, Network Engineer가 각기 파트 마다 작업을 하지만, 각기 파트를 아예 모르면 Client에 대한 Service의 수준이 낮아 짐... 서로의 파트에 대한 전반적 이해가 있어야, 각기 구성시 제공하는 Solution이 잘 돌아가야 하는게 목적이기 때문.

ㄴ Storage system

1. Direct Attached Storage(직접연결)

peer to peer로 연결하는데, storage 하나에 server가 10대일 경우 모두 개별 연결하기 어렵기 때문에, 기본적으로 잘 사용을 하진 않는다. (** 하지만 VMware에서 권고하는 환경은 Shared Storage)

2. Network Attached Storage(Network 연결)

NFS/ISCSi 두가지가 있다. 

3. SAN Storage

SAN Storage

Network cable이 아닌 광Cable로 연결하는 Storage가 있는데 이게 SAN 형태이다. 

ㄴ Operation System

---

ㅁ 이중화(Redundancy) & 고 가용성(High availability)

특정 System 또는 device에 대해 예삐장치 1개 이상 추가하여 SPOF(single point of Failure)상황을 방지하는 이중화와, Service가 지속적으로 가동 될 수 있도록 상태를 구성하는 고가용성 개념 

ㄴ 이중화(Redundancy) - 장비(장치)에 대한 이중화를 통해 SPOF상황 방지

ㄴ HA(Service의 연속성) - Service down time을 최소화 해서 다른 Host를 통해 service의 재가동 목적(Service의 지속)