wowza vod 서버 개념
vod 는 일단 storage 가 있다. 이 storage 에 사업자(content provider) 가 upload 를 하게 하려고, upload server(deamon) 를 띄운다. 그리고 이 storage 를 http 로 접근하게 하기 위해 web server 를 하나 띄우는데, 그게 norg 라고 부르자.이 norg 를 wowza (여기서는 vod service 를 해주는 edge server) 가 이용한다. 근데, 계속 norg 에 접근하면 norg 부하가 있으니, media cache 라는 것을 가능하게 설정할 수 있다.(wowza 에서 상용을 이용하는 사람에게 제공해 준다고 함.)
이 media cache 의 동작은 이렇다.
일단 wowza 로 어떤 video 를 보겠다고 요청이 들어오면, wowza 가 norg 를 통해서 해당하는 녀석을 읽어올 것이다. 그런데 이 wowza 가 이 해당하는 video 를 통째로 다 한번에 wowza 로 가져와서 end user 에게 전달해 주지 않는다.
이 wowza 가 end user 에게 필요한 부분만 부분적으로 norg에 요청을 하고, (이것을 range request 라고 한다고 한다.) 이 부분을 가져와서 보여준다. 그리고, media cache 에도 저장해 놓는다.(이부분은 불분명하다. wowza 의 media cache 가 norg 에서 가져오고, wowza 의 VOD server 부분이 그것을 이용하는 것이 맞을 수도 있다. media cache 설정에 base url 을 설정해 줄 때 norg 를 설정해 준다고 한다.(확인필요))
이 wowza vod server 에서 제공해 주는 protocol 은
- rtmp
- http
- hls(apple)
- hds(adobe)
- silverlight
- rtsp
가 있다. http 는 다시 hls(apple), hds(adobe), silverlight 로 나눌 수 있다.
rtsp 는 UDP 를 사용하고 554 port 를 사용한다. 하지만 나머지 2개는 TCP 를 사용한다. 그리고 port 는 1935 를 사용한다. 하지만 1935를 막아놓은 경우가 많아서, 대체 port 로 80, 554 를 같이 열어 놓아서 이 port 를 통해 end user 에서 접근할 수 있게 해 놓는다고 한다.
참고:
range request 의 status code 는 206 이라고 한다.
wowzad의 media cache 가 norg 에게 range request 를 요청할 때 최소단위가 5MB 라고 한다. 그래서 당연히 media cache 도 최고 5MB 단위로 저장을 하게 되겠다.
이 media cache 에 저장하는 방법은 해당 file 에 대한 공간을 잡아놓고 wowza 가 norg 에서 가져온 부분만 저장해 놓는다. 쉽게 p2p 에서 파일 다운로드 받는 것을 생각하면 된다.
media cache 는 이런 식으로 caching 을 해 놓는다.
norg에서 아무처리도 하지 않는데, wowza 가 norg 에서 파일에 대한 정보(파일사이즈 등)를 가져가고 media cache 에 그만큼의 용량을 확보해 놓는다고 한다. 하지만 이 부분은 애매하다. 보통은 토렌트의 seed 파일 같은 녀석이 존재해야 할 듯 한데, 그렇지 않다면, file 을 직접 읽기 모드로 열어서 extension(확장자)에 따라 원하는 부분에서 header 부분을 가져오는지도 모르겠다. 아니면, 단순히 size 정도라면 http header 의 처음 부분만 보고 거기서 수신을 강제로 끊어버리는 것도 가능할 듯 하다.
wowza vod server 에 purge 를 요청하면 media cache 에 있는 media 의 property 정보를 가지고 있는 pros 지우고, media 파일을 지운다.
wowza 는 java 로 되어 있다. 그래서 VM 이 돌고 있는데, 이 VM 에서 purge 후에 삭제되었는지 여부를 알 수 있다고 한다. 구체적으로는 해봐야 알 듯 하다.
Media Cache
http://www.wowza.com/forums/content.php?121-How-to-get-MediaCache-AddOn-(scale-video-on-demand-streaming)&page=2#comments1) Mediacache should not add any perceivable delays to the streaming. When a video is first requested, the video metadata (size etc) is grabbed first and then the cache reserves that amount of space for the file by creating a zero filled file of the same size. It only gets the actual file data from the remote source at the time it is actually requested and saves it in the local file. If another player requests the same video, it first looks to see if the chunks are already local or currently being requested and if not then requests them from the remote file. The delay in getting the remote chunks would be the time it takes to service the request to the remote server. If the server is on the same network then there should be no noticeable delay. The request chunk size can be tuned to suit your storage system and network.
2) When content is added to the cache, the following will happen.
The cache will attempt to flush old files that have not been accessed recently. There are two TTL settings, MaxTimeToLive and MinTimeToLive. In normal operation, the old content is removed based on the Max TTL setting from when it was last accessed. When a new piece of content needs to be added to the cache, it first checks if there is enough space. If not then it will attempt to flush old content based on the Min TTL setting until there is enough space freed up and then it will be added.
If enough space cannot be freed for the new content then it is not added to the cache. Instead, the cache is bypassed for the entire file and instead, the requests from the players go directly to the source. These requests are at the size that the player requests and are normally a lot smaller than the cache requests. From your storage server perspective, it would be no different to what you would see if the storage server was set as a networked partition that Wowza accesses directly. Existing content in the cache would still make requests as normal.
It shouldn't add any extra delays but it may put more load on your storage server and network.
In a production environment, you should size the MediaCacheStores based on the amount of unique content you expect to be serving at the same time. If you have 100 1GB files and you expect that 50 of them may be watched at the same time then you would set your cache to be at least 50GB. If you only expect 10 to watched at the same time then you could set the cache size to 10GB. These are theoretical figures. The cache mechanism does add a few extra KB per item to store it's own information about the item.
If the file system has more space available that the store size set in the configuration then it is possible adjust the store size while the server is running without having to restart by using the JMX interface. The new setting should be put into the Mediacache.xml file so that it will be used on restart.
What a lot of people do though is use a separate SSD drive and set the cache to use the entire partition. Another suggestion, if there is enough free memory, is to use a memory based tmpfs partition which would be even faster than an SSD drive. Tmpfs uses swap space so there shouldn't have problems with memory allocation, as long as the swap space is large enough. Having an SSD drive configured for swap along with a tmpfs partition would make an excellent Mediacache store.
Another important aspect with Mediacache is how the sources are accessed. MediaCache will read from file based sources (local file system or NFS, CIFS etc) or from HTTP based sources such as an Apache or IIS web server or Amazon S3 or OpenStack. Even if the storage server local to the wowza servers, we recommend configuring your storage server to use HTTP rather than a networked file system as it is more resilient to network problems. NFS can cause server lockups if the link goes down but with HTTP, the connection will just timeout after a few seconds.
댓글 없음:
댓글 쓰기