1 / 34

Windows Terminal Services for Remote PVSS Access

Windows Terminal Services for Remote PVSS Access. Peter Chochula – ALICE 17 June 2004. Outline. Motivation Technology : RDP, RDC, Windows Server 2003 CERNTS, licensing issues ALICE Test Setup Tests to be performed. Motivation for using TS.

myrona
Download Presentation

Windows Terminal Services for Remote PVSS Access

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Windows Terminal Services for Remote PVSS Access Peter Chochula – ALICE 17 June 2004

  2. Outline • Motivation • Technology : RDP, RDC, Windows Server 2003 • CERNTS, licensing issues • ALICE Test Setup • Tests to be performed

  3. Motivation for using TS • Remote access to control systems is required by several groups • We were looking for secure and reliable solution • Number of protocols passing through CERN’s firewall should be limited to minimum • CERN’s security team recommends TS in conjunction with PVSS remote UI as a preferred solution

  4. Remote Connection to Control Systems (basic ideas) Control System Remote client CERN’s firewall W2003 TS PVSS Remote UI Remote desktop connection over VPN PVSS Master Projects

  5. Technology behind the Windows TS • Windows 2003 TS component is an evolution of Terminal Services • Allows for delivery of Windows based applications to remote (even non-Windows) computers • Secure communication with clients is based on RDP (remote data protocol

  6. Remote desktop clients (RDC) • Implemented in Windows XP • Clients available for • Windows 95/98/98SE/ME/NT4/2k • Windows CE – allows for using palmtops on client side! • Linux • MAC OS X 10.2.8 or later • Web based interface available for ActiveX enabled browsers

  7. Client Resource redirection • File System • Client drives are mounted inside server session • Ports • Client COM and LPT ports can be mounted to the server • Audio • Sound can be redirected to client • Printers • Client printers (including networked) are visible to server • Windows keys • Combinations such as ALT-TAB etc. can be redirected to server (CTRL-ALT-DEL is disabled for security reasons)

  8. Additional features • Time Zone redirection • RDC client can provide its time zone to the server – this allows for working across different time zones (makes sense for agenda etc.) • Virtual channels • provide possibility to enhance communication between client and application running on server • Roaming disconnects • Allow for reconnection to disconnected sessions • Clipboard mapping • Copy/Paste support between client and server • 24-bit color support

  9. Benefits from TS and RDC • Centralized maintenance of remote UI projects • No need to install project on each client machine • Low-bandwidth access to data • Only screen view of the data is transmitted • RDP provides techniques such as data compression or persistent bitmap caching • Connection optimization based on network bandwidth • High level of security • 128 bit bi-directional RC4 encryption (client dependent) • Additional FIPS compliant encryption level

  10. Enhancing security on TS • TS user rights can be assigned to individual users or groups • Software restriction policies • Administrators can allow only certain programs to be run by specified users • Client settings can be overridden by server • Client access can be restricted to PVSS00NV, (closing this application would terminate the connection)

  11. Windows TS capacity • MS provides tools for measuring the performance of servers • Rough estimates based on “Knowledged workers” and “Data Entry workers” groups (as defined by the Gartner group) • Server is considered to be at capacity when it is 10% slower as it was with single user load • Numbers should be taken as a guide, real test must be done with PVSS in order to verify our real needs

  12. Server capacity estimate

  13. Estimated memory requirements • Total recommended memory for TS: 128 MB + (# of users) * (Memory per user) • Where memory per user can be estimated as • 9.5 MB for Knowledge workers • 3.5 MB for Data Entry workers • We measured ~3-30 MB for Remote UI projects (very very preliminary)

  14. Windows 2003 Server Editions • Four editions available • Web edition (no TS support) • Standard Edition • Enterprise Edition • Datacenter Edition (optimized for mission critical applications - large database servers etc. ) • In our evaluation we focused on Standard and Enterprise editions

  15. Comparison between Standard and Enterprise Editions • Only “relevant” parameters are listed • For details see http://www.microsoft.com/windowsserver2003/evaluation/features/compareeditions.mspx

  16. Overview of TS licensing • Two licensing modes • Per user • Per device • License is issued to the client by the server • License server provides a pool of licenses • Licenses are not returned to the pool after disconnecting the session • E.g. a colleague using a laptop goes away with the license • Reformatting a client disk wipes out the license • Unused licenses will be returned to pool after a timeout period (~80 days) • If the connection to licensing server is lost, TS issues temporary licenses to clients

  17. TS at CERN • Central service provided by CERN’s IT is now operational (CERNTS) • User rights are restricted to minimum (basically the user is allowed to use only the Office applications) • No possibility to install new software by the user • PVSS support not foreseen

  18. Cloning of CERN TS for experiments • No manpower for central maintenance of additional TS available • We were offered help with installation of the servers and setting-up of licensing and local policies • Credits and thanks to Ruben D. Gaspar Aparicio • BUT!: • We can profit from CERN License Server • A reasonable number of licenses (~5000) available at CERN (out of them ~300 presently in use)

  19. Test Setup in ALICE CERN network Private network RDC 2x W2003 Enterprise Edition running TS RDC PVSS Master Projects PVSS Master Projects

  20. Tests to perform • A preliminary list of tests to be performed has been prepared • Credits Wayne, Bruce • Some test were already done – as a proof of the concept • Systematic tests will be performed this summer • Everyone is invited to participate • Following slides show the status and should trigger discussion

  21. Tests to perform • Understand what is needed to set-up a WTS able to run PVSS UIM • Present status: • 2 Servers installed (180 day trial of Enterprise Edition) and created remote UI projects • To be done: • Check if this is what we need • People should have a look at the service and comment

  22. Tests to perform • Understand what is needed to set-up a WTS cluster able to run PVSS UIM • Present status: • NLB cluster setup in progress – it will be setup on private network • To be done: • Test the performance • Decide if we really need a server cluster (tending to say “no”)

  23. Tests to perform • Understand how to set-up the access to multiple different (10) of PVSS systems • Present status: • Simultaneous access to 2 systems tested (even across CERN’s firewall) • To be done: • Test the performance • Perform tests with more realistic (big) projects (scheduled for early July)

  24. Tests to perform • Understand the load of the WTS in the previous cases • Present status: • Rough estimate done, will be repeated with proper tools • To be done: • Perform tests with realistic (big) projects • Sort of “data challenge” would be needed • Your help would be really appreciated

  25. Tests to perform • Look on the effect on users if one user initiates a high CPU-load task • Present status: • Tested a policy which allows to execute only remote UI projects • High CPU-load tasks can be killed by administrator • Test should be done with proper tools – e.g. Values from Task Manager could be misleading. We will follow the test methodology proposed by Microsoft • To be done: • Identify high CPU-load tasks which are needed • Look on the effects and define policies • See how clustering helps

  26. Tests to perform • Try access to the WTS from Windows machines (XP,2000,NT), Linux and MAC • Present status: • We tested RDC with XP, Windows 2000, Windows 98 SE and Linux • To be done: • Perform tests with MAC, Windows CE ….

  27. Tests to perform • Determine the behavior if the connection between WTS and PVSS is lost (also on PVSS system if any) • Present status: • Temporary cut the connection between WTS and network • Operation correctly resumes if the disconnection is shorter than ~7s • Otherwise the remote UI loses connection and has to be restarted • No effects on master PVSS project observed • To be done: • Perform real tests

  28. Tests to perform • Determine the behavior if the connection to the WTS is lost (also on PVSS system if any) • Present status: • RDC allows for re-connection to a disconnected session – tested even across CERN’s firewall (and it works) • On server side a policy can be defined which kills disconnected sessions after a predefined timeout • We were able to reconnect to a session even after 3 days • To be done: • Perform more tests with big systems ( also on NLB cluster to check the roaming)

  29. Tests to perform • Identify the requirements for licensing • Present status: • Discussed with IT, our test server is recognized by CERN License server • Seems to work (tested with ~20 simultaneous connections to WTS) • To be done: • Read again the description of non-trivial MS licensing model • Follow the developments of Longhorn Servers (present licensing model is completely different from W2000) • Discuss future support with IT

  30. Tests to perform • Look at any possible security issues with this approach and how to minimize the risk • Present status: • The approach is recommended by CERN security team • Additional tests scheduled in ALICE for July • A firewall will be placed between the WTS and PVSS projects running on private network • Several tests will be performed at private network (Administrative Circular Nr. 5 restricts the tests on CERN’s network) • To be done: • This is a critical issue with many consequences and has to be studied carefully with help of CERN Security and Network teams • One should especially look at resource sharing as this is a potential source of problems

  31. Tests to perform • Look at how to handle login (single or multiple) • Present status: • We looked so far only at local policies and defined a group of users • To be done: • This topic has to be followed – what are the requirements? • The client can securely share credentials with WTS • File system permission between Windows and Unix could be also handled by Windows Services for Unix (SFU) – it provides NFS server and client, password synchronization etc. (we installed SFU and will test it soon)

  32. Tests to perform • Look at performance when changing frequently the panels or when panels are frequently modified • Present status: • Pending • To be done: • It has to be done

  33. Additional tests • All tests should be done more systematically and with more realistic systems • So far we tried just to check the concept • Identify bottlenecks (e.g. network influence) • Understand user requirements • Study related technologies (e.g. SFU, SUS…) • What else did we forget?

  34. Conclusions • Concept of TS has been studied in ALICE • Test setup including 2 Enterprise servers is operational (we will be forced to reinstall at least one server by the end of July – grace period is over) • No major problems discovered so far • We will continue our tests and report the results • Any help is appreciated

More Related