Sql-server – Which server actually runs the SSIS package when SQL Agent and SSISDB are on 2 different servers

I would suggest reading up on SSIS at MSDN: Initial Installation (Integration Services) -this references having a standalone installat of just SSIS.

Quote from above link:

SQL Server Integration Services is installed through the SQL Server 2008 Setup program. You can install Integration Services alongside other SQL Server components or you can install Integration Services as a stand-alone component. Integration Services includes both client and server applications.

To use a dedicated server for extraction, transformation, and loading (ETL) processes, we recommend that you install a local instance of the SQL Server Database Engine when you install Integration Services. Integration Services typically stores packages in an instance of the Database Engine and relies on SQL Server Agent for scheduling those packages. If the ETL server does not have an instance of the Database Engine, you will have to schedule or run packages from a server that does have an instance of the Database Engine. This means that the packages will not be running on the ETL server, but instead on the server from which they were started. As a result, the resources of the dedicated ETL server are not being used as intended. Furthemore, the resources of other servers might be strained by the running ETL processes.

Some additional information could be found here as well: Considerations for Installing Integration Services. You might want to take under consideration the licensing as well and still validate the standalone server is licensed properly.

Yes, most likely. This is a short answer, but it sounds like you are really just asking - Can a job on SQL Server 2008 calling an SSIS package built on 2008 connect to a database in SQL Server 2012 and do some work within that database?

SSIS can connect to many OLEDB/ODBC compliant connections. You could, for instance use an SSIS 2008 (or 2005 or 2012) Package to read data from one Oracle database, do some transformations and the write the results of that to another Oracle database, never talking to SQL except the SSIS engine.

So an SSIS package in 2008 should be able to work with a connection to 2012. Some caveats like - if you are using a deprecated command structure in an execute SQL task - it will fail.. Or test it and verify first. But this should work, if you are just asking if - from within the SSIS package can I talk to SQL Server 2012.