MDS 可以用匿名帐号访问，或是经由一台已经通过 GSI 认证的代理来访问。应用程序开发人员需要保证，能够在必要的时候通过一台经过认证的代理。您的网格环境可能具有多级别的目录结构。根据环境及其拓扑的复杂程度不同，您应该保证能够访问适当的目录，在其中搜索您所要求的资源。
数据管理
当您在构建网格的时候，网格中最重要的资产就是您的数据。在您的设计当中，您将必须确定您对数据的需求，以及如何在整个基础设施中移动数据，要么就是如何用一种安全有效的方式访问所需的数据。您可以通过一组标准化的网格协议与您设计的任何数据资源进行通信。您也可以选择构建一个联邦数据库，创建一个虚拟的数据存储。还有其他一些选择，如存储区域网(Srorage Area Network)、网络文件系统，以及专用的存储服务器等。
Globus 为网格环境提供了 GridFTP 和 Global Access to Secondary Storage(GASS)两种数据传输机制。此外，它还提供了一种复制管理机制，可以帮助您管理和访问数据集的副本。在应用程序中启用网格时的考虑：数据管理。数据管理问题源自如何最大化地使用有限的存储空间、网络带宽、计算资源等。下面列出一些在应用程序设计和实现中需要考虑的数据管理问题：
数据集的大小。对于大的数据集来说，要想将它移动到实际运行任务的系统上是不现实，甚至是不可能的。可能的解决方案是使用数据复制、或将完整数据集的一个子集拷贝到目标系统中。地理上分散的用户、数据、计算以及存储资源。如果您的目标网格在地理上是分散的，网络连接的速度也有限，那么您在设计的时候就必须考虑到如何进行慢速和受限的数据访问。
在广域网上进行数据传输。当您要在 Internet 或者其他的 WAN 上移动数据时，必须考虑安全性、可靠性以及性能等问题。您必须构建一些必要的逻辑来处理数据访问速度慢，甚至被阻断的情况。数据传输的调度。下面两种情况至少要考虑一种：第一个是数据传输的调度，这样当需要某项数据的时候数据就在它适当的位置上了。比如说，如果数据传输需要进行一个小时，而使用这项数据的任务必须在凌晨两点钟开始运行，那么您就应该提前对数据传输进行调度，这样，当需要它的任务运行的时候，数据就是可用的了。第二个是了解进出任何一项资源的任何并发文件传输的数量与规模。
选择数据副本。如果您使用 Globus Data Replication 服务，也许想向应用程序中增加一段选择适当副本的逻辑，也就是说，您想要选择一个包含所需数据的副本，同时还要满足您对性能的要求。
调度器
Globus Toolkit 没有提供任务调度器，也没有提供元任务调度器(-scheduler)。不过，有一些任务调度器已经和 Globus 集成起来了，还有一些也可以集成进来。
在网格中，任务调度与负载平衡是十分重要的功能。大多数网格系统中都包括某种任务调度软件。这种软件可以查找到某台机器的位置，并在上面执行用户提交的网格任务。有些调度器实现了按照任务优先级进行调度的系统。优先级的实现方式有时是使用多个任务队列，其中每一个队列都代表不同的优先级。当网格计算机可以执行任务的时候，就从优先级最高的队列中取出第一个任务。通过调度器还可以实现各种不同类型的策略。策略中可以包含多种对任务、用户、以及资源的约束。比如说，可能有一种策略限制在一天的某些特定时间执行网格任务。
调度器通常会对实时网格负载做出反应。它们在提交任务之前，会用反映当前机器使用情况的量测信息来确定哪些机器不忙。调度器可以组织成层次结构。比如说，元调度器将任务提交给群集调度器，或其他低层调度器，而不直接提交给独立的计算机。更高级些的调度器可以对所调度的任务的执行过程进行监视，从而对整体工作流实施管理。如果由于系统或网络的原因而导致一些任务丢失，好的调度器会自动在别的地方重新提交任务。然而，如果某个任务进入死循环，运行的时间超过了某个最大时间，那么这样的任务就不应该再重新调度了。典型情况下，各种任务具有不同类型的结束代码，其中一些结束代码适合于用于重新提交任务，而另一些则不适合。
我们通过一个预约系统可以实现在网格中提前保留资源。这种机制不仅仅是调度器。它首先是一种基于日历的系统，可以在特定的时间段内保留资源，防止其他任务在同一时间内使用该资源。它还必须能在预约的时间到达的时候将任意机器或资源上正在执行的任务删除或挂起。
在应用程序中启用网格时的考虑：调度器。当您为网格环境启用应用程序的时候，需要考虑一些与调度有关的问题。下面列出其中一些：
数据管理。意思是保证当所调度的任务运行时具备可用的数据。如果需要将数据移动到待执行的节点上，那么我们还需要对数据的移动操作也进行调度。
通信。任何相关任务的进程间通信都要求对任务进行并行调度。
调度器的作用域。在具有多个调度器(如具备元调度器)的环境中，要协调并发任务，或保证特定的任务在指定的时间执行，这些工作的复杂程度很高，当不同的调度器具有不同的作用域时，情况就更加复杂。
调度策略。调度可以有不同的实现目标。
面向应用程序——调度的优化目标是实现最佳运行时间。
面向系统——调度的优化目标是实现最大吞吐量。任务可能不会立即开始。在执行的过程中也可能被终端或抢占。也可以将任务调度为通宵执行。
网格信息服务。调度器和信息服务之间的交互可能十分复杂。比如说，如果在任务实际运行之前通过 MDS 找到了某项资源，然后，我们可以假设在任务实际运行之前该资源的状态不会发生变化。或者我们可以建立一种预测能力更强的机制，提前预测资源状态可能发生的变化，从而提前做出调度决定。
资源代理。通常情况下，资源代理必须与调度器接口。
负载平衡。负载平衡问题是由于工作负载在网格系统资源中的分散特性所引起的。尽管 Globus Toolkit 没有提供负载平衡的功能，而在某些特定环境中，负载平衡服务却是必需的特性。当作业被提交到网格任务管理器中时，工作负载可以通过推模式(push model)、拉模式(pull model)或组合模式(combined model)进行分布。推模式的简单实现是通过循环的方式将任务发送到网格资源上。然而，这个模型没有考虑到任务队列的长度。如果每一个网格资源上都发送到相同数目的任务，那么在速度较慢的机器上会形成较长的任务队列，而一个长时间运行的任务在不受到细心监视的情况下可能阻塞其他的任务，使之根本无法启动。对于这个问题，一种解决方案是使用加权循环的方案。
在拉模式中，网格资源从任务队列中获取任务。在这样的模式下，任务队列的同步化与串行化就成为协调多个网格资源的任务获取的必要手段。本地及全局任务队列的策略也是可行的。在本地拉模式策略中，每一组网格资源都指派为从一个本地任务队列获取任务。在全局拉模式策略中，所有的网格资源都被指派使用同一个任务队列。本地拉模式的优势在于能够对网格资源进行分片。比如说，离数据比较接近的，或相互有关的，或要求使用相似资源的某些任务，都可以用这种方法进行控制。
推模式和拉模式的组合模式可以解决前面提到的一些问题。每一个网格资源可以决定何时能接收更多的工作，并向网格任务服务器发送工作请求。然后，任务服务器就向其发送新的工作。
在这两种负载平衡模式下，都需要考虑故障恢复的条件。我们需要检测出哪些网格资源已经无法继续操作了，在推模式中，不能把新的工作发送给已经失效的资源。此外，无论是在推模式还是在拉模式中，我们必须细心控制所有已经提交的但尚未完成的任务。失效主机上的所有未完成任务都需要进行重新分配，或者由同一组中的其他可运行主机接管过来。
在应用程序中启用网格时的考虑：负载平衡。当您为网格环境启用应用程序的时候，还需要考虑与负载平衡有关的设计问题。应用程序设计和开发人员需要理解目前的负载平衡机制是什么样子(手工、推、拉、或是某种混合模式)，这会对应用程序，特别是它的性能和运行时间产生影响。如果应用程序中具有大量独立的任务，每一个都可能受到负载平衡系统的影响或控制，那么这样的应用程序就可以从网格整体性能和吞吐量的提高当中获益，不过这个应用程序也可能需要建立更加复杂的机制，以便处理将任务延迟、或在整个网格内移动任务所带来的复杂性问题。
代理。在网格环境中，代理的职责非常重要。在很多网格环境中都可能需要实现这个组件，而实现它的方法可以相对简单，也可能十分复杂。代理的基本职责是在服务请求者和服务提供者之间提供匹配服务。在网格环境中，服务请求者可能是应用程序，也可能是被提交执行的任务。服务提供者就是网格资源。
Globus 工具箱并没有提供代理的功能。不过它通过监视与发现服务(MDS)提供了网格信息服务。您可以对 MDS 进行查询，从而发现主机、计算机和网络的属性，如当前可用处理器个数、所提供的带宽以及可用的存储类型等等。
在应用程序中启用网格时的考虑：代理。当您设计在网格环境中运行的应用程序时，很重要的一点是理解资源是如何被发现和分配的。可能需要应用程序告诉代理它的资源要求是什么，这样代理就可以保证给这个应用程序分配适当的资源。
进程间通信(IPC)网格系统中可能包含帮助任务之间相互通信的软件。比如说，应用程序可能会将自身划分为大量的子任务。这些子任务当中的每一个都是网格中的一个独立的任务。不过，应用程序的算法可能要求子任务之间相互通信，传递一些信息。这些子任务要能够定位其他特定的子任务，与之建立通信连接，并发送适当的数据。消息传递接口(Message Passing Interface，MPI)是一项开放标准，它及其若干变种经常作为网格系统的一部分来解决诸如此类的问题。
在应用程序中启用网格时的考虑：IPC。在任务之间进行进程间通信的需求总是会增加应用程序的复杂程度，因此只要有可能，您就应该将这种通信减到最少。然而，在大规模的复杂应用程序中，进程间通信通常是不可避免的。在这种情况下，您应该充分理解可用的 IPC 机制，并将失败或通信速度变慢带来的影响降到最低，这样有助于保证整个应用程序的成功。
非功能性需求 |
